Perl/FastCGI - What happens on exit?

[DreamT]

Hi,
Consider this code:

use CGI::Fast qw(:standard);

while ($query = new CGI::Fast)
{
       # Do stuff

       exit if $exit_flag == 0;
}

Can you describe what happens, both on a Perl level and on a webserver(Apache) level?
I know that the instance is exited, and reloaded the next time when the script is run. But I'd like to understand what exactly happen.

I have a problem on a certain Apache server that the application dies for a while, before Apache "wakes up".

[sundialsvc4]

Any FastCGI server is a persistent process, usually but not necessarily spawned by Apache, which sits on one end of an inter-process communication (IPC) channel with Apache at the other end.   When Apache gets a request and decides that it’s for FastCGI, it sends a message down the channel.   One of the servers picks it up, generates the reply, and sends it back to Apache.   Then, the server goes back to sleep again.   Meanwhile, Apache grabs the response and sends it back to the client.

I happen to prefer to do things this way, vs. mod_perl, because it keeps the Apache request-handlers small and also because it lets me deploy the FastCGI servers behind an internal firewall, where they are being fed by Apache/nginix servers that themselves don’t have access to anything.   (There’s just a soda-straw sized opening between the two, and only FastCGI data can get through.)   A really big operation might have several different servers handling different URLs.   I often use the Plack module for this interface, vs. the one you are using here, but that’s just me or my habit.   (And I don’t want to divert this thread into a philosophical debate on these points.)

Clearly, this package sleeps in the constructor, hands back an object containing the request, and captures whatever you print as the response that is to be returned, taking care of the delivery and plumbing behind-the-scenes like a good package should.

Now, specifically addressing your question about exit:   Every now and again, a FastCGI server will choose to “commit hari-kiri,” voluntarily terminating itself (e.g. to curtail the effect of memory leaks).   Apache will re-spawn its replacement.   That’s what you see in the $exit_flag bit ... which is clearly just a for-instance.   For instance, you might arbitrarily decide that a module should service, say, 1,000 requests and then terminate so that the OS can clean-up its memory.   So you’d initialize and increment a counter, then exit when it reached or exceeded 1,000.   I presume that this module catches the attempt so that it can send the response data back to Apache and close the connection before the process actually dies.   Also, IIRC, you can call for hari-kiri behavior in the Apache configuration settings, asking Apache to keep a count and to kill its darlings.   One way or the other, Apache (or a FastCGI monitoring daemon of some kind) sees the body, cleans it up, then grabs another “instant FastCGI service process, just add water!” package and adds water to it.   :-)   A replacement instance of the FastCGI process is now off-and-running, and life goes on blissfully as it should.

Do be mindful that there is more-than-one Apache module available for FastCGI support, and that the two are not quite the same.   This package, IIRC, is using the “newer” one of the two, as it should.   I think that the original, mod_fastcgi, is now considered deprecated.

[afoken]

I happen to prefer to do things this way, vs. mod_perl, because it keeps the Apache request-handlers small and also because it lets me deploy the FastCGI servers behind an internal firewall, where they are being fed by Apache/nginix servers that themselves don’t have access to anything.

Even in a less sophisticated setup, FastCGI still allows to use different users for the webserver and the FastCGI process. So an administrator can grant only minimal privileges to both processes, whereas for mod_perl, the Apache process must have the sum of all privileges required by all mod_perl applications.

Another nice feature is that a crashing FastCGI application does not kill the web server, unlike a mod_perl application.

Alexander