FastCGI error (perl 5.003/libfcgiv1.5 + apache v1.1.1)

Steve Kann (stevek@io360.com)
Mon, 19 Aug 1996 10:43:36 -0400 (EDT)

From: Steve Kann <stevek@io360.com>
Message-Id: <199608191443.KAA12180@spheara.io360.com>
Subject: FastCGI error (perl 5.003/libfcgiv1.5 + apache v1.1.1)
To: fastcgi-developers@openmarket.com
Date: Mon, 19 Aug 1996 10:43:36 -0400 (EDT)

Hi all,

	I just came in this morning, to find that our fastcgi home page
had been down almost all weekend.
	
	The server logs show this for each request:

[Mon Aug 19 09:35:36 1996] access to /var/httpd/main/htdocs/v2/index.html.fcgi failed for spheara.io360.com, reason: HTTPd: error connecting to fastcgi server - filename: /var/httpd/main/htdocs/v2/index.html.fcgi - error: No such file or directory 

Looking through the module code, there are only 5 places where this can
happen:

[ listings omitted ]

And although I haven't figured out which one of these is actually
generating the erros, digging through the code led me to solving the
problem:

The problem was that the server makes it's socket in /tmp.  I have a
perl script that scans my filesystem every 6 hours or so, and, amongst
other things, removes files in /tmp that are older than three days. 

I'm pretty sure my scanner went and unlinked the socket in
/tmp (OM_WS_??????), and that was causing these fatal errors in the
webserver.

I'm going to go and tame my scanner and have it _not_ remove sockets or
devices, but more generally, I think it would be nice if the server
could restart the fastcgi process if an error like this happens.  Would
the OpenMarket server die the same horrible death from this kind of
thing?

This whole fastcgi approach is very neat, but at the same time
inherently less stable than the traditional cgi interface, as such, I
think that lots of "failsafe" mechanisms are warranted.  Maybe, what is
needed is a "if all else fails, run it a CGI" mechanism, since fastcgi
programs are always designed to work under both interfaces.

-SteveK