DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10266>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10266 apache hangs after some hours of running [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | Version|2.0.39 |2.0.43 ------- Additional Comments From [EMAIL PROTECTED] 2002-11-24 18:14 ------- I am reopening this bug report. It was closed because I could not confirm it on the latest Apache 2.0.43 because we have been unable to do the upgrade. This week we installed a brand spanking new SUN V100 Server. We placed 2.0.43 apache on it and we turned on two virtuals. Pretty much same configuration file as used on our other servers. We began seeing the hang problem within the first 24 hours of running. Note that there was practically no hits to the system. Since this bug report was unresolved and was causing our systems to hang... we wrote a monitor program a few months ago that senses for the hang and sends a HUP to the process. If the process does not recover it will shut down ALL the apache processes and do a restart. This monitor pings apache about once every 15 seconds and so can detect and fix the problem almost immediatly. We have noted interesting things - specifically, the watchdog has never had to kill apache - the HUP always works. The problem might not occur for days, and then might occur many times in a day. Very unpredictable. We have also noted that apache can apparently also *fix* the problem. That is, the process hangs for maybe 30 minutes or so, and then unhangs and everything is ok (we know this becuase we were not watching one apache process thinking it was immune, and then discovered it was doing this). This MIGHT be one reason this is hard to track down, because apache does apparently resolve it eventually. Just as an interest, here is the restart info from our watchdog program - note the times, etc: 11/23/2002 18:59:12 -> Trouble #1 for 192.207.247.2 192.207.247.2 not responding, HUPing with: kill -USR1 `cat /cookware/web/apache/logs/httpd.pid` 11/23/2002 22:20:30 -> Trouble #1 for 192.207.247.2 192.207.247.2 not responding, HUPing with: kill -USR1 `cat /cookware/web/apache/logs/httpd.pid` 11/23/2002 23:34:14 -> Trouble #1 for 192.207.247.2 192.207.247.2 not responding, HUPing with: kill -USR1 `cat /cookware/web/apache/logs/httpd.pid` 11/23/2002 23:40:00 -> Trouble #1 for 192.207.247.2 192.207.247.2 not responding, HUPing with: kill -USR1 `cat /cookware/web/apache/logs/httpd.pid` 11/23/2002 23:40:50 -> Trouble #1 for 192.207.247.2 192.207.247.2 not responding, trying again: kill -USR1 `cat /cookware/web/apache/logs/httpd.pid` 11/23/2002 23:55:45 -> Trouble #1 for 192.207.247.2 192.207.247.2 not responding, HUPing with: kill -USR1 `cat /cookware/web/apache/logs/httpd.pid` 11/24/2002 01:13:32 -> Trouble #1 for 192.207.247.2 192.207.247.2 not responding, HUPing with: kill -USR1 `cat /cookware/web/apache/logs/httpd.pid` 11/24/2002 05:24:50 -> Trouble #1 for 192.207.247.2 etc.... So apparently it can appear in clusters, and then not appear for hours or days. I also feel your bug #12598 is also related to this problem - probably describing the same situation. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
