You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Jim Albert <ji...@netrition.com> on 2005/05/11 20:54:57 UTC
[users@httpd] Signal handling (SIGPIPE) change
Is anyone aware of a change in signal handling by apache httpd from
somewhere perhaps between versions 2.0.49 and 2.0.52 of apache?
It seems to me that apache would previously catch a sigpipe once it
noticed that the pipe from server to client was broken; most likely by
someone pressing the stop button.
It would then immediately send a signal to kill any running CGI.
I'm running apache 2.0.52 with mod_perl 2 and perl 5.8.5 and I have a
test CGI that does lots of output to stdout so that it should cause a
sigpipe if the browser quits. Sometime prior to apache 2.0.52 this was
the case.
However, now it appears that this test CGI is allowed to continue until
it has finished. I used to have to catch the SIGPIPE in apache (via a
PerlFixupHandler with mod_perl) to prevent the httpd child from killing
my CGI. I seem to no longer need to do that with apache 2.0.52. I'm fine
with that behavior, but just trying to convince myself of why it is I'm
seeing this.
I know there have been signal changes with perl as of version 5.8
however, I don't believe this is a mod_perl or perl issue. I .foo'd my
conf.d/perl.conf file to turn off mod_perl just to check and I still
witness the same behavior... my test CGI finishes to completion.
I checked the apache changes logs, but didn't see anything that looked
relevant.
Sound familiar to anyone? Thanks for any help.
--
Jim Albert
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Signal handling (SIGPIPE) change
Posted by Jim Albert <ji...@netrition.com>.
I do use DBI.pm to connect to a mysql database in various situations,
however I am not preloading any mysql modules into the apache server nor
does my test CGI make use of mysql in any way. So mysql is not an issue
in my question.
From what I am seeing in Apache 2.0.52, the apache httpd process is
getting the SIGPIPE. However, it appears that it does not get the
SIGPIPE or at least does not act on the SIGPIPE until my CGI process
ends even though there is lots of printing to stdout by the CGI all
throught its execution which in the past was enough to immediately
generate a SIGPIPE.
At some point in the past (I believe at least as early as Apache
2.0.49), the apache httpd process would act on the SIGPIPE as soon as it
was generated and kill any running CGI process.
btw... my test CGI process is a perl script using perl 5.8.5. However,
as stated below, I do not believe this is related to some change in
perl's signal handling.
It seems to me this would be something that others would have witnessed
and be concerned with as some people likely relied on apache killing off
their CGIs as soon as possible following an event that triggered a
SIGPIPE. For example, some CGI that consumes lots of computer resources
so that if the user wants to stop the request prior to finishing, the
CGI is killed.
Perhaps there is something unusual with my configuration that is causing
this behavior, but I'm not seeing anything.
Joshua Kugler wrote:
> You aren't perchance using a MySQL library are you? libmysql clears SIGPIPE
> on initialization, so you might need to set your handlers after that. I ran
> into that issue a while back Worth a try?
>
> If you're not using MySQL, well, never mind. :)
>
> j----- k-----
>
> On Wednesday 11 May 2005 10:54, Jim Albert wrote:
>
>>Is anyone aware of a change in signal handling by apache httpd from
>>somewhere perhaps between versions 2.0.49 and 2.0.52 of apache?
>>
>>It seems to me that apache would previously catch a sigpipe once it
>>noticed that the pipe from server to client was broken; most likely by
>>someone pressing the stop button.
>>
>>It would then immediately send a signal to kill any running CGI.
>>
>>I'm running apache 2.0.52 with mod_perl 2 and perl 5.8.5 and I have a
>>test CGI that does lots of output to stdout so that it should cause a
>>sigpipe if the browser quits. Sometime prior to apache 2.0.52 this was
>>the case.
>>
>>However, now it appears that this test CGI is allowed to continue until
>>it has finished. I used to have to catch the SIGPIPE in apache (via a
>>PerlFixupHandler with mod_perl) to prevent the httpd child from killing
>>my CGI. I seem to no longer need to do that with apache 2.0.52. I'm fine
>>with that behavior, but just trying to convince myself of why it is I'm
>>seeing this.
>>
>>I know there have been signal changes with perl as of version 5.8
>>however, I don't believe this is a mod_perl or perl issue. I .foo'd my
>>conf.d/perl.conf file to turn off mod_perl just to check and I still
>>witness the same behavior... my test CGI finishes to completion.
>>
>>I checked the apache changes logs, but didn't see anything that looked
>>relevant.
>>
>>Sound familiar to anyone? Thanks for any help.
>
>
--
Jim Albert
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Signal handling (SIGPIPE) change
Posted by Joshua Kugler <jo...@uaf.edu>.
You aren't perchance using a MySQL library are you? libmysql clears SIGPIPE
on initialization, so you might need to set your handlers after that. I ran
into that issue a while back Worth a try?
If you're not using MySQL, well, never mind. :)
j----- k-----
On Wednesday 11 May 2005 10:54, Jim Albert wrote:
> Is anyone aware of a change in signal handling by apache httpd from
> somewhere perhaps between versions 2.0.49 and 2.0.52 of apache?
>
> It seems to me that apache would previously catch a sigpipe once it
> noticed that the pipe from server to client was broken; most likely by
> someone pressing the stop button.
>
> It would then immediately send a signal to kill any running CGI.
>
> I'm running apache 2.0.52 with mod_perl 2 and perl 5.8.5 and I have a
> test CGI that does lots of output to stdout so that it should cause a
> sigpipe if the browser quits. Sometime prior to apache 2.0.52 this was
> the case.
>
> However, now it appears that this test CGI is allowed to continue until
> it has finished. I used to have to catch the SIGPIPE in apache (via a
> PerlFixupHandler with mod_perl) to prevent the httpd child from killing
> my CGI. I seem to no longer need to do that with apache 2.0.52. I'm fine
> with that behavior, but just trying to convince myself of why it is I'm
> seeing this.
>
> I know there have been signal changes with perl as of version 5.8
> however, I don't believe this is a mod_perl or perl issue. I .foo'd my
> conf.d/perl.conf file to turn off mod_perl just to check and I still
> witness the same behavior... my test CGI finishes to completion.
>
> I checked the apache changes logs, but didn't see anything that looked
> relevant.
>
> Sound familiar to anyone? Thanks for any help.
--
Joshua Kugler
CDE System Administrator
http://distance.uaf.edu/
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org