handle fastcgi signals

http://www.fastcgi.com/devkit/doc/fcgi-spec.html#S7
> A Web server can request that a FastCGI application exit by sending it
> SIGTERM. If the application ignores SIGTERM the Web server can resort
> to SIGKILL.

So stop accepting new requests after receiving a TERM signal.  Allow the
current page to finish, we should assume it won't be long (long-running
scripts usually require customized destructors anyway, so don't account
for those).  This is quite important to prevent interrupted output.

According to http://www.fastcgi.com/docs/faq.html#Signals Apache
mod_fastcgi will send a SIGUSR1 in addition to the TERM.  Seems safe to
ignore these.

If a client aborts a connection, we'll get a SIGPIPE.  Because the page
may still have crucial actions to perform, we should ignore and finish
the code.  Pages can easily handle PIPEs themselves if wanted.

The LastCall method is used, even though FCGI 0.67 warns:
> Note that this method is still experimental and everything about it,
> including its name, is subject to change.

As it's stable since september 2001, I guess it'll be fine for now.

diff --git a/PLP/Backend/FastCGI.pm b/PLP/Backend/FastCGI.pm
index 205ece19e7e577b6544ea478388cf22832c9992e..f83675a7ce3963244a6df7caef0c846ed94c2d37 100644 (file)
--- a/PLP/Backend/FastCGI.pm
+++ b/PLP/Backend/FastCGI.pm
@@ -6,11 +6,15 @@ use PLP::Backend::CGI;
 use FCGI;
 use base 'PLP::Backend::CGI';
 
-our $VERSION = '1.00';
+our $VERSION = '1.01';
 
 sub import {
        my $self = shift;
        my $request = FCGI::Request();
+       $SIG{TERM} = sub {
+               $request->LastCall();
+       };
+       $SIG{PIPE} = 'IGNORE';
        while ($request->Accept() >= 0) {
                $PLP::use_cache = !defined $ENV{PLP_CACHE} || $ENV{PLP_CACHE}; # before it's clean()ed
                delete $ENV{PATH_TRANSLATED};