[EMAIL PROTECTED] 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, Christopher -- Oh My God! They Killed init! You Bastards!!
