You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Jim Albert <ji...@netrition.com> on 2004/06/15 23:55:19 UTC
perl 5.8 safe signals and broken pipes in apache
Last week I had a problem where I could not get my
Apache2/mod_perl2/perl5.8.3 web server to catch a SIGPIPE signal in a
timely manner. I was asked to post a description of this problem and
solution to this list so that it might be included in future mod_perl
documentation.
Feel free to adjust this description as necessary when integrating it
into the appropriate documentation.
The Problem:
Use a PerlFixupHandler to catch when the pipe from browser to httpd
server has been broken such as when the user presses the browser stop
button.
In conf.d/perl.conf
PerlFixupHandler Apache::SIG2
where Apache::SIG2.pm is defined in this example as:
----------
package Apache::SIG2;
# This package adapted by Jim Albert from the original mod_perl1
# Apache::SIG.pm by Doug MacEachern and Doug Bagley
# This PerlHandler can be used to prevent httpd children from killing
# off non-mod-perled CGIs when the user presses the Stop button.
use strict;
use Apache::RequestRec;
use ModPerl::Util;
use Apache::Const;
sub handler {
my $r = shift;
if (!$r->main) {
$SIG{PIPE} = \&PIPE;
}
return OK;
}
sub PIPE {
my($signal) = @_;
print STDERR ("User pressed stop button.\n");
# Kill off the httpd child before it can kill any running CGIs.
# Or do whatever other cleanup is appropriate.
CORE::exit();
}
1;
----------
With the introduction of perl 5.8.0, this handler no longer works as
expected because of the introduction of perl safe signals.
See:
http://www.perldoc.com/perl5.8.4/pod/perlipc.html#Deferred-Signals-(Safe-Signals)
What happens with perl 5.8 and safe signals is that the apache httpd
child does receive the SIGPIPE, but it is delayed and the perl CGI
program has already been killed. The httpd child does not act on the
SIGPIPE until it receives the next httpd request.
The Solution:
An Apache server_startup.pl script can be used to turn off perl safe
signals with the following line:
$ENV{PERL_SIGNALS} = "unsafe";
The server_startup.pl script can be included via the following line in
perl.conf:
PerlRequire conf/server_startup.pl
The ability to revert back to "unsafe" signals is available as of perl
5.8.1.
--
Jim Albert
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
FreeBSD 4.10 ports change that affects Storable
Posted by Eric <er...@dmcontact.com>.
Hi,
I was just reminded of this happening and thought it might be useful to people here since lots of people like me use Storable for persistence with mod_perl.
FreeBSD 4.10 changed the way Perl is compiled in the ports collection. They added the use64bitint flag which was not there before. That led to some issues with Storable that the Storable perldoc goes into in a lot of detail. It was all one big adventure until I found that out about the ports change. We never had a problem with Storable working across different databases on different machines until this happened. I just thought it might be a good warning to put out.. You will end up with the version errors that the perldoc talks about. See 64 bit data in perl 5.6.0 and 5.6.1
I ended up just removing the use64bitint and did a make deinstall make clean etc...
But I guess in the sprit of my last post I really should make a conversion program to load the old Storable data and re-write it with the new. Otherwise the next FreeBSD update could lead to a headache... :)
Thanks,
Eric
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: perl 5.8 safe signals and broken pipes in apache
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Stas Bekman wrote:
>
>> Eric Frazier wrote:
>>
>> Jim, Eric, so can you please put this thread together into one doc
>> piece that can be added to the docs?
>
>
> so any chance someone can put together the solutions from Eric and Jim,
> and the other suggestions I gave in the reply to the Jim's original
> question? And then we will add them to the online docs. I'd really like
> to concentrate on finishing the mp2 API at this time, to get mp2 out
> sooner. So your help is appreciated.
>
> The relevant threads are:
> http://marc.theaimsgroup.com/?t=108681694700001&r=1&w=2
> http://marc.theaimsgroup.com/?t=108733667200002&r=1&w=2
Well, it's now documented here:
http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#Problems_with_Catching_Signals_under_Perl_5_8_x_
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: perl 5.8 safe signals and broken pipes in apache
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Eric Frazier wrote:
>
> Jim, Eric, so can you please put this thread together into one doc piece
> that can be added to the docs?
so any chance someone can put together the solutions from Eric and Jim,
and the other suggestions I gave in the reply to the Jim's original
question? And then we will add them to the online docs. I'd really like
to concentrate on finishing the mp2 API at this time, to get mp2 out
sooner. So your help is appreciated.
The relevant threads are:
http://marc.theaimsgroup.com/?t=108681694700001&r=1&w=2
http://marc.theaimsgroup.com/?t=108733667200002&r=1&w=2
Thanks.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[OT] Re: perl 5.8 safe signals and broken pipes in apache - now mod_perl blacklisted
Posted by Lupe Christoph <lu...@lupe-christoph.de>.
On Wednesday, 2004-06-30 at 13:42:16 -0700, Eric Frazier wrote:
> Who ever is admining your mail server might want to look into using a
> *responsible* list. Spews routinely causes horror for many innocents,
> sometimes blocking whole datacenters over one account.
For this partivular case, please read
http://spews.org/ask.cgi?S3056
> Almost any other list is an improvement, I have noticed many lists follow
> along behind http://www.spamhaus.org/ for example, and they have reasonable
> people you can talk to. It is MUCH more likely you will fix the problem by
> getting your admin to change his blacklist choice than that you will be
> able to get the mod_perl list off the spews listing. They will only rinse
> and repeat, "Get rid of the spammer, or move your ISP"
> Yes, folks, it is that bad these days. spam means unsolicited email, but
> also it means lots of people don't get their legitimate email. I frankly
> think the whole thing is a nightmare with no end in sight..
Off-topic (I'm only using perl for this, not mod_perl ;-) )
Since last weekend, I'm collecting RBL hits and misses for spam and ham.
Spews is definitely a bad idea. It blocks hermes.apache.org even at
level 1.
I have written a Perl program that tries to find the "best" RBLs. It
eliminates all RBLs that hit servers delivering ham. Then it lets me
manually insert RBLs, then it selects by effectiveness. I manually set
Chian/Korea blocking and blocking of dynamically assigned addresses.
Without manually set RBLs, the hitlist is this:
cbl.abuseat.org dynablock.njabl.org no-more-funn.moensted.dk
bl.spamcop.net dnsbl-2.uceprotect.net list.dsbl.org spam.dnsbl.sorbs.net
cn-kr.blackholes.us multihop.dsbl.org psbl.surriel.com sbl.spamhaus.org
dul.dnsbl.sorbs.net dnsbl-3.uceprotect.net ipwhois.rfc-ignorant.org
mail-abuse.blacklist.jippg.org
cbl.abuseat.org dynablock.njabl.org no-more-funn.moensted.dk
bl.spamcop.net catch 90% of the spamming adresses. uceprotect and
rfc-ignorant are too dangerous and will probably eliminated by the
false-positive checker in a while.
I have 18 IP addresses that sent Spam and were not blocked by any list,
even the most aggressive ones. 27 addresses were only recognized by
aggressive lists, 264 are recognized by the above list of RBLs.
Here are the overly aggressive RBLs:
blackholes.five-ten-sg.com
block.blars.org
l1.spews.dnsbl.sorbs.net
l2.spews.dnsbl.sorbs.net
spews.blackholes.us
dnsbl.jammconsulting.com
Whoever read this far and is still interested - mail me if you want the
code.
HTH,
Lupe Christoph
--
| lupe@lupe-christoph.de | http://www.lupe-christoph.de/ |
| "... putting a mail server on the Internet without filtering is like |
| covering yourself with barbecue sauce and breaking into the Charity |
| Home for Badgers with Rabies. Michael Lucas |
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: perl 5.8 safe signals and broken pipes in apache - now
mod_perl blacklisted
Posted by Eric Frazier <er...@dmcontact.com>.
Hi,
Who ever is admining your mail server might want to look into using a
*responsible* list. Spews routinely causes horror for many innocents,
sometimes blocking whole datacenters over one account.
Almost any other list is an improvement, I have noticed many lists follow
along behind http://www.spamhaus.org/ for example, and they have reasonable
people you can talk to. It is MUCH more likely you will fix the problem by
getting your admin to change his blacklist choice than that you will be
able to get the mod_perl list off the spews listing. They will only rinse
and repeat, "Get rid of the spammer, or move your ISP"
Yes, folks, it is that bad these days. spam means unsolicited email, but
also it means lots of people don't get their legitimate email. I frankly
think the whole thing is a nightmare with no end in sight..
Thanks,
Eric
At 01:10 PM 6/30/2004, Jim Albert wrote:
>Stas Bekman wrote:
>
>>Eric Frazier wrote:
>>Jim, Eric, so can you please put this thread together into one doc piece
>>that can be added to the docs?
>
>I had just noticed that I received none of the mod_perl mailings in the
>past 10 days or so. Looks like the mod_perl list mail server is on a spam
>blacklist.
>
>relay=hermes.apache.org [209.237.227.199]
>Rejected from 209.237.227.199 - see http://spews.org/bounce.html
>
>I understand spews is one of the more aggressive blacklists, but perhaps
>one the list admins should look into getting this IP out of spews?
>
>--
>Jim Albert
>
>
>
>--
>Report problems: http://perl.apache.org/bugs/
>Mail list info: http://perl.apache.org/maillist/modperl.html
>List etiquette: http://perl.apache.org/maillist/email-etiquette.html
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: perl 5.8 safe signals and broken pipes in apache
Posted by Jim Albert <ji...@netrition.com>.
Stas Bekman wrote:
> Jim Albert wrote:
>
>> Stas Bekman wrote:
>>
>>> Eric Frazier wrote:
>>>
>>> Jim, Eric, so can you please put this thread together into one doc
>>> piece that can be added to the docs?
>>>
>>>
>>
>> I had just noticed that I received none of the mod_perl mailings in
>> the past 10 days or so. Looks like the mod_perl list mail server is
>> on a spam blacklist.
>>
>> relay=hermes.apache.org [209.237.227.199]
>> Rejected from 209.237.227.199 - see http://spews.org/bounce.html
>>
>> I understand spews is one of the more aggressive blacklists, but
>> perhaps one the list admins should look into getting this IP out of
>> spews?
>
>
> This issue was raised on the apache infrastructure list and someone told
> that one shouldn't even bother to do that, because of the draconian
> rules spews.org uses (I'm just repeating their words) and I guess the
> admins aren't going to do that. Therefore there is nothing we can do
> about it. I suppose you could contact infrastructure #at# apache.org.
>
Not a big deal; one can always allow access to a particular server on
their own mail server if they decide to trust the server. If the admins
don't want to make an attempt to get the IP pulled out of spews, I
wouldn't push it.
--
Jim Albert
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: perl 5.8 safe signals and broken pipes in apache
Posted by Stas Bekman <st...@stason.org>.
Jim Albert wrote:
> Stas Bekman wrote:
>
>> Eric Frazier wrote:
>>
>> Jim, Eric, so can you please put this thread together into one doc
>> piece that can be added to the docs?
>>
>>
>
> I had just noticed that I received none of the mod_perl mailings in the
> past 10 days or so. Looks like the mod_perl list mail server is on a
> spam blacklist.
>
> relay=hermes.apache.org [209.237.227.199]
> Rejected from 209.237.227.199 - see http://spews.org/bounce.html
>
> I understand spews is one of the more aggressive blacklists, but perhaps
> one the list admins should look into getting this IP out of spews?
This issue was raised on the apache infrastructure list and someone told that
one shouldn't even bother to do that, because of the draconian rules spews.org
uses (I'm just repeating their words) and I guess the admins aren't going to
do that. Therefore there is nothing we can do about it. I suppose you could
contact infrastructure #at# apache.org.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: perl 5.8 safe signals and broken pipes in apache
Posted by Jim Albert <ji...@netrition.com>.
Stas Bekman wrote:
> Eric Frazier wrote:
>
> Jim, Eric, so can you please put this thread together into one doc piece
> that can be added to the docs?
>
>
I had just noticed that I received none of the mod_perl mailings in the
past 10 days or so. Looks like the mod_perl list mail server is on a
spam blacklist.
relay=hermes.apache.org [209.237.227.199]
Rejected from 209.237.227.199 - see http://spews.org/bounce.html
I understand spews is one of the more aggressive blacklists, but perhaps
one the list admins should look into getting this IP out of spews?
--
Jim Albert
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: perl 5.8 safe signals and broken pipes in apache
Posted by Stas Bekman <st...@stason.org>.
Eric Frazier wrote:
Jim, Eric, so can you please put this thread together into one doc piece that
can be added to the docs?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: perl 5.8 safe signals and broken pipes in apache
Posted by Eric Frazier <er...@dmcontact.com>.
Hi,
Very glad I could be of some help, even though most of this was copy and paste and googling. I was in fact testing this on a FreeBSD server with 5.8.0, the production server is 5.8.4.
Eric
At 03:39 PM 6/15/2004, Jim Albert wrote:
>Great! It's always nice to have multiple solutions to a problem. I believe Stas Bekman also pointed to the POSIX sigaction solution when he first pointed me in the right direction in solving this problem, but setting $ENV{PERL_SIGNALS} = "unsafe"; got me going with perl 5.8 very quickly.
>
>I might give the POSIX sigaction solution a try myself since I too wasn't incredibly comfortable with resorting to old signal handling for my entire httpd servers. My guess is that your POSIX sigaction solution would work with perl5.8.0 unlike the $ENV{PERL_SIGNALS} solution which is not supported until perl5.8.1.
>
>Assuming your solution also solves this problem, it should also be included in any documentation regarding "safe signals" and apache/mod_perl.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: perl 5.8 safe signals and broken pipes in apache
Posted by Jim Albert <ji...@netrition.com>.
Great! It's always nice to have multiple solutions to a problem. I
believe Stas Bekman also pointed to the POSIX sigaction solution when he
first pointed me in the right direction in solving this problem, but
setting $ENV{PERL_SIGNALS} = "unsafe"; got me going with perl 5.8 very
quickly.
I might give the POSIX sigaction solution a try myself since I too
wasn't incredibly comfortable with resorting to old signal handling for
my entire httpd servers. My guess is that your POSIX sigaction solution
would work with perl5.8.0 unlike the $ENV{PERL_SIGNALS} solution which
is not supported until perl5.8.1.
Assuming your solution also solves this problem, it should also be
included in any documentation regarding "safe signals" and apache/mod_perl.
Eric wrote:
> Jim,
>
> Thank you! This was a big help to me in that I ran into this problem from two directions recently, with a perl daemon and with Apache::SIG.. I did find some info about fixing this for real rather than using unsafe signals. They mostly seemed to point to using the POSIX sigaction methods rather Perl's.
>
> I did end up getting my daemon to work without either dying after the first command or spawning endless children that would not die, those were my two choices before :) Only a part of this was related to the signal problem, but it was the hard part for a while.
>
> The child signal was what was causing me big problems. I know this is far from a complete answer, but I hope it might send someone off on the right path if they don't want to set the ENV var. I was worried about doing it that way, because what happens a year from now when I upgrade my server and we somehow forget about that little detail? I know me and I will manage to mess it up if I can :)
>
> Below are some examples from the POSIX module, it should work :). I found most of this somewhere when doing research on perl daemons but the child one I added on and I am currently using all of the below, I just did some cutting of other things.
>
> use POSIX ();
> use POSIX 'WNOHANG';
> use FindBin ();
> use File::Basename ();
> use File::Spec::Functions;
>
> my $script = File::Basename::basename($0);
> my $SELF = catfile $FindBin::Bin, $script;
>
> my $sigset = POSIX::SigSet->new();
> my $action = POSIX::SigAction->new('sigHUP_handler',
> $sigset,
> &POSIX::SA_NODEFER);
> my $action_alrm = POSIX::SigAction->new('sigALRM_handler',
> $sigset,
> &POSIX::SA_NODEFER);
> my $action_child = POSIX::SigAction->new('sigCHLD_handler',
> $sigset,
> &POSIX::SA_NODEFER);
>
> POSIX::sigaction(&POSIX::SIGHUP, $action);
> POSIX::sigaction(&POSIX::SIGALRM, $action_alrm);
> POSIX::sigaction(&POSIX::SIGCHLD, $action_child);
>
> sub sigHUP_handler {
> print "got SIGHUP\n";
> exec($SELF, @ARGV) or die "Couldn't restart: $!\n";
> }
> sub sigALRM_handler {
> print "got ALARM timeout\n";
>
> }
> sub sigCHLD_handler {
> while (my $reaperpid = waitpid(-1,WNOHANG)>0) {
> }
> }
>
>
> ## do your while (1) and fork etc...
>
>
>
> I wish I could paste in my whole daemon thing, but it is too far along with to many things specific to my bosses application..
>
> Thanks,
>
> Eric
>
> At 02:55 PM 6/15/2004, Jim Albert wrote:
>
>>Last week I had a problem where I could not get my Apache2/mod_perl2/perl5.8.3 web server to catch a SIGPIPE signal in a timely manner. I was asked to post a description of this problem and solution to this list so that it might be included in future mod_perl documentation.
>>
>>Feel free to adjust this description as necessary when integrating it into the appropriate documentation.
>>
>>The Problem:
>>Use a PerlFixupHandler to catch when the pipe from browser to httpd server has been broken such as when the user presses the browser stop button.
>>
>>In conf.d/perl.conf
>>PerlFixupHandler Apache::SIG2
>>
>>where Apache::SIG2.pm is defined in this example as:
>>
>>----------
>>package Apache::SIG2;
>>
>># This package adapted by Jim Albert from the original mod_perl1
>># Apache::SIG.pm by Doug MacEachern and Doug Bagley
>># This PerlHandler can be used to prevent httpd children from killing
>># off non-mod-perled CGIs when the user presses the Stop button.
>>
>>use strict;
>>use Apache::RequestRec;
>>use ModPerl::Util;
>>use Apache::Const;
>>
>>sub handler {
>> my $r = shift;
>> if (!$r->main) {
>> $SIG{PIPE} = \&PIPE;
>> }
>>
>> return OK;
>>}
>>
>>sub PIPE {
>> my($signal) = @_;
>> print STDERR ("User pressed stop button.\n");
>> # Kill off the httpd child before it can kill any running CGIs.
>> # Or do whatever other cleanup is appropriate.
>> CORE::exit();
>>}
>>
>>1;
>>----------
>>
>>With the introduction of perl 5.8.0, this handler no longer works as expected because of the introduction of perl safe signals.
>>See:
>>http://www.perldoc.com/perl5.8.4/pod/perlipc.html#Deferred-Signals-(Safe-Signals)
>>
>>What happens with perl 5.8 and safe signals is that the apache httpd child does receive the SIGPIPE, but it is delayed and the perl CGI program has already been killed. The httpd child does not act on the SIGPIPE until it receives the next httpd request.
>>
>>The Solution:
>>An Apache server_startup.pl script can be used to turn off perl safe signals with the following line:
>>$ENV{PERL_SIGNALS} = "unsafe";
>>The server_startup.pl script can be included via the following line in perl.conf:
>>PerlRequire conf/server_startup.pl
>>The ability to revert back to "unsafe" signals is available as of perl 5.8.1.
>>
>>--
>>Jim Albert
>>
>>
>>
>>--
>>Report problems: http://perl.apache.org/bugs/
>>Mail list info: http://perl.apache.org/maillist/modperl.html
>>List etiquette: http://perl.apache.org/maillist/email-etiquette.html
>
>
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: perl 5.8 safe signals and broken pipes in apache
Posted by Eric <er...@dmcontact.com>.
Jim,
Thank you! This was a big help to me in that I ran into this problem from two directions recently, with a perl daemon and with Apache::SIG.. I did find some info about fixing this for real rather than using unsafe signals. They mostly seemed to point to using the POSIX sigaction methods rather Perl's.
I did end up getting my daemon to work without either dying after the first command or spawning endless children that would not die, those were my two choices before :) Only a part of this was related to the signal problem, but it was the hard part for a while.
The child signal was what was causing me big problems. I know this is far from a complete answer, but I hope it might send someone off on the right path if they don't want to set the ENV var. I was worried about doing it that way, because what happens a year from now when I upgrade my server and we somehow forget about that little detail? I know me and I will manage to mess it up if I can :)
Below are some examples from the POSIX module, it should work :). I found most of this somewhere when doing research on perl daemons but the child one I added on and I am currently using all of the below, I just did some cutting of other things.
use POSIX ();
use POSIX 'WNOHANG';
use FindBin ();
use File::Basename ();
use File::Spec::Functions;
my $script = File::Basename::basename($0);
my $SELF = catfile $FindBin::Bin, $script;
my $sigset = POSIX::SigSet->new();
my $action = POSIX::SigAction->new('sigHUP_handler',
$sigset,
&POSIX::SA_NODEFER);
my $action_alrm = POSIX::SigAction->new('sigALRM_handler',
$sigset,
&POSIX::SA_NODEFER);
my $action_child = POSIX::SigAction->new('sigCHLD_handler',
$sigset,
&POSIX::SA_NODEFER);
POSIX::sigaction(&POSIX::SIGHUP, $action);
POSIX::sigaction(&POSIX::SIGALRM, $action_alrm);
POSIX::sigaction(&POSIX::SIGCHLD, $action_child);
sub sigHUP_handler {
print "got SIGHUP\n";
exec($SELF, @ARGV) or die "Couldn't restart: $!\n";
}
sub sigALRM_handler {
print "got ALARM timeout\n";
}
sub sigCHLD_handler {
while (my $reaperpid = waitpid(-1,WNOHANG)>0) {
}
}
## do your while (1) and fork etc...
I wish I could paste in my whole daemon thing, but it is too far along with to many things specific to my bosses application..
Thanks,
Eric
At 02:55 PM 6/15/2004, Jim Albert wrote:
>Last week I had a problem where I could not get my Apache2/mod_perl2/perl5.8.3 web server to catch a SIGPIPE signal in a timely manner. I was asked to post a description of this problem and solution to this list so that it might be included in future mod_perl documentation.
>
>Feel free to adjust this description as necessary when integrating it into the appropriate documentation.
>
>The Problem:
>Use a PerlFixupHandler to catch when the pipe from browser to httpd server has been broken such as when the user presses the browser stop button.
>
>In conf.d/perl.conf
>PerlFixupHandler Apache::SIG2
>
>where Apache::SIG2.pm is defined in this example as:
>
>----------
>package Apache::SIG2;
>
># This package adapted by Jim Albert from the original mod_perl1
># Apache::SIG.pm by Doug MacEachern and Doug Bagley
># This PerlHandler can be used to prevent httpd children from killing
># off non-mod-perled CGIs when the user presses the Stop button.
>
>use strict;
>use Apache::RequestRec;
>use ModPerl::Util;
>use Apache::Const;
>
>sub handler {
> my $r = shift;
> if (!$r->main) {
> $SIG{PIPE} = \&PIPE;
> }
>
> return OK;
>}
>
>sub PIPE {
> my($signal) = @_;
> print STDERR ("User pressed stop button.\n");
> # Kill off the httpd child before it can kill any running CGIs.
> # Or do whatever other cleanup is appropriate.
> CORE::exit();
>}
>
>1;
>----------
>
>With the introduction of perl 5.8.0, this handler no longer works as expected because of the introduction of perl safe signals.
>See:
>http://www.perldoc.com/perl5.8.4/pod/perlipc.html#Deferred-Signals-(Safe-Signals)
>
>What happens with perl 5.8 and safe signals is that the apache httpd child does receive the SIGPIPE, but it is delayed and the perl CGI program has already been killed. The httpd child does not act on the SIGPIPE until it receives the next httpd request.
>
>The Solution:
>An Apache server_startup.pl script can be used to turn off perl safe signals with the following line:
>$ENV{PERL_SIGNALS} = "unsafe";
>The server_startup.pl script can be included via the following line in perl.conf:
>PerlRequire conf/server_startup.pl
>The ability to revert back to "unsafe" signals is available as of perl 5.8.1.
>
>--
>Jim Albert
>
>
>
>--
>Report problems: http://perl.apache.org/bugs/
>Mail list info: http://perl.apache.org/maillist/modperl.html
>List etiquette: http://perl.apache.org/maillist/email-etiquette.html
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html