httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Albert <>
Subject [users@httpd] Signal handling (SIGPIPE) change
Date Wed, 11 May 2005 18:54:57 GMT
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 

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:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message