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@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|