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