www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher W. Curtis" <ccur...@aet-usa.com>
Subject Re: os-solaris/3467: Broken client connections not detected
Date Tue, 01 Dec 1998 23:30:01 GMT
The following reply was made to PR os-solaris/3467; it has been noted by GNATS.

From: "Christopher W. Curtis" <ccurtis@aet-usa.com>
To: marc@apache.org
Cc: apache-bugdb@apache.org, apbugs@apache.org
Subject: Re: os-solaris/3467: Broken client connections not detected
Date: Tue, 01 Dec 1998 18:21:24 -0500

 marc@apache.org wrote:
 > Synopsis: Broken client connections not detected
 > State-Changed-From-To: open-feedback
 > State-Changed-By: marc
 > State-Changed-When: Tue Dec  1 09:22:47 PST 1998
 > State-Changed-Why:
 > Do you have any reason for thinking this is an Apache issue
 > and not a PHP issue?
 I posted it to the PHP list, but it seems unlikely to me that PHP would
 be it.  PHP does not patch anything in Apache, and I am 99.997% sure
 that PHP is using the Apache-style read/write calls (PHP implements
 flush() because Apache buffers writes...).  I looked at the code in
 http_main.c and think I know where the signal is being ignored, but I'm
 not familiar enough with the internals to know why everything happening
 in there that is.  It does appear to make sense to ignore the signal,
 but for some reason the child is not exiting gracefully when it should. 
 Maybe there is a hook that PHP uses to disable the pending_signal (was
 that it?) check; I really don't know.  Neither Rasmus or Jim (both of
 whom are on the PHP list) have said anything about it, so I would have
 to conclude that they would agree here, but that may be presumptuous.
 I was going to truss further for you, but the server is hosed again and
 I need to drive over to reboot it.  From what I remember, after the
 ignored SIGPIPE, there was an alerm(0); some setsigprocmask()s (two
 statements, I forget exactly which); then another alarm(non-zero).
 Apache/PHP and this script are apparently killing the server not less
 than twice a day, on average, since yesterday.  A netstat -a shows each
 of these connections in a FIN_WAIT2, and the server-status handler show
 that they will stick in "G" mode when given a -USR1.  When given a -HUP
 signal, httpd blocks for up to several minutes, presumably waiting to
 rebind to the port.  Again, here, I'm not too sure the details...
 Thanks for any help,
 Oh My God!  They Killed init!  You Bastards!!

View raw message