fpCGI failure

[Fairlight]

Only Tyler would say something like:
> > What does apache's access_log and error_log have to say about it?  Do they
> > succeed with 200's, or are there errors, and if so, what is the extended
> > error information from error_log?
> 
> 
> No idea.  If I knew where to find them, I could tell you, but maintaining
> apache/fpcgi is contracted out.

Erm...SCO system?  I assume it's probably SCO's build, so it's likely under
/usr/local/apache or /usr/local/lib/apache  (possibly suffixed with a
2...it's been a while).  Under whichever it is, there should be a logs
directory.

> > from fP is ^G (bell).  In all the years I've done CGI with fP, I've never
> > seen a single instance of other contents.
> 
> No output here either.

A redirect of stderr is 0 bytes?  Then it's not kicking up something it
considers an error worth beeping over.

> > Or maybe the process takes > ~5min and apache is giving up on the entire
> > lot before they're done.
> 
> Not the case, and shouldn't block fpCGI from running other
> processes/reports.
> 
> I'd actually like to know if the report/clerk processes are hanging around,
> > or are they gone?  Check the process table.
> >
> 
> Gone.
> 
> Thanks for the advice and questions...hopefully with enough dirt thrown up,
> we can find the bodies...

The problem with throwing up a lot of dirt is that it obscures the vision.
:)

You've made reference to other reports running just fine.  What happens if
you replicate the necessary parts of the environment at the shell level,
throw your processing for the fpcgi-based stuff into debug mode, and run it
from the command line without fpcgi in the mix at all?  Same table, either
with or without debug, but will it run -outside- the context of fpcgi?
Just create the flat ASCII file fpcgi would, fake the environment, and see
what happens.  It's the sanest idea at this point.

mark->
-- 
"Moral cowardice will surely be written as the cause on the death
certificate of what used to be Western Civilization." --James P. Hogan