fpCGI failure

[Fairlight]

On Thu, Mar 13, 2008 at 01:48:17PM -0400, after drawing runes in goat's blood,
Nancy Palmquist cast forth these immortal, mystical words:
> Tyler wrote:
> > fpCGI, both v1 and 2, bombs out on our Apache2 web server running 
> > fp5.0.14 on SCO OS 6.  It simply stops outputting HTML files for any 
> > rreports run.  It requires rebooting the entire machine to get it going 
> > again.  Running the commands thru fpcgi that it was stalling on works 
> > perfectly fine after the reboot.
> > 
> > Via our resller via Ray at fptech, Ron at fptech says that it looks like 
> > an application error, and that we should just set Field_nohtmlfound to 
> > some other page.  This is obviously unsatisfactory.
> > 
> > Can anyone shed any light on this, or how to avoid it?

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?

> I use fpCGI 2.0 extensively, and I am not sure you might not be
> experiencing a timing issue.

Possibly, but I'm looking at it from another angle.  More below.

> End the filepro command line with something like this:
>
> 1>/tmp/report1 2>/tmp/report2

You can safely ignore stderr.  The only thing that will ever be in stderr
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.

> Run your app and then look to see if /tmp/report2 has anything (errors go
> here)

I've always redirected both, and the only thing I've ever seen is ^G in the
stderr channel.  It's far more helpful to check the screen output in
stdout.

> Also maybe something is not waiting long enough.  Make sure you do not
> have fpCGI only waiting 20 sec, but your report takes 30 sec to run.

Or maybe the process takes > ~5min and apache is giving up on the entire
lot before they're done.

Apache2 is also pretty insane about its cleanup process.  Namely, one issue
is that if you close all three main file descriptors (0, 1, and 2), your
process will be killed even if it's still running.  This idiom has been
used to start background tasks after reporting to the client since time
immemorial, but it's unavoidable without hacking apache2.  There are other
odd things it does.

I'd actually like to know if the report/clerk processes are hanging around,
or are they gone?  Check the process table.

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