Signals w/ FastCGI & Perl

ace (ace@interzon.com)
Tue, 18 Mar 1997 13:53:37 -0700 (MST) 

Date: Tue, 18 Mar 1997 13:53:37 -0700 (MST)
From: ace <ace@interzon.com>
To: fastcgi-developers@OpenMarket.com
Subject: Signals w/ FastCGI & Perl
Message-Id: <Pine.LNX.3.91.970318133400.17090A-100000@ClarkNova.interzon.com>

Sorry if this question has come up before, but has anyone had 
problems with signals using FastCGI and Perl on Linux?

I built perl w/ the plug-in FastCGI stuff (I didn't go the sfio route).  
I used Perl5.003. My operating system is Linux 2.0.28.

When I set up a signal handler, the FastCGI-modified perl interpreter 
ignores it and runs the default handler when a signal is received.  The 
same code works fine with a non-FastCGI-modified perl interpreter.  For 
example:

sub handler{ 
	$signal = @_;
	print "received signal $signal.\n";
}

$SIG{USR1}=\&handler;
$SIG{INT}=\&handler;

while(true) {
	print "sleeping.\n";
	sleep 2;
}

With this code, if I 'kill -USR1 xxxx" the process will simply print 
"User signal 1." and die.  Similar responses come from all other signals.
With the non-FastCGI modified interpreter, when I 'kill -USR1' I get 
"received signal USR1." just like I was hoping.  

This behavior makes it very hard to write code to trap a signal and terminate 
a FastCGI process in the manner described recently on this list as a 
good way to restart FastCGI apps.  I'm assuming there is something wrong 
with the FastCGI modifications to the Perl interpreter, although it could 
just as easily be that I'm missing a major concept somewhere along the 
way here :). 

Is there anyone who knows more about this that could give me some help?  
Or at least another way to restart my FastCGI apps without restarting 
the server? Thanks very much.

 -Ace Thompson
  ace@interzon.com