Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Restarting of httpd always fails for me after a httpd relevant update, like a php update or httpd update itself. I don't think, it's IPv6 relevant (but I can't be really sure), even if the error displays my IPv6 address, but I'm also able to get the error at a IPv4 only box (but very very very rare there). BTW, the IPv6 I replaced by "[My IPv6]" is the last configured IPv6 (out of 3) in the ssl.conf - maybe it's relevant, I dunno. Version-Release number of selected component (if applicable): httpd-2.0.50-5 httpd-2.0.50-6 httpd-2.0.50-7 (maybe also with older httpd versions, but I don't have older here) How reproducible: Everytime, see below - I know, it's maybe a little bit tricky, but very annoying. Steps to Reproduce: --- snipp --- # rpm -Uvh php*-4.3.8-11.i386.rpm Preparing... ########################################### [100%] 1:php-mbstring ########################################### [ 14%] 2:php-gd ########################################### [ 29%] 3:php-ncurses ########################################### [ 43%] 4:php-pear ########################################### [ 57%] 5:php-mysql ########################################### [ 71%] 6:php-devel ########################################### [ 86%] 7:php ########################################### [100%] # # service httpd restart httpd beenden: [ OK ] httpd starten: (98)Address already in use: make_sock: could not bind to address [My IPv6]:443 no listening sockets available, shutting down Unable to open logs [FAILED] # # ps -A | grep http 32691 ? 00:00:05 httpd 32692 ? 00:00:02 httpd 32693 ? 00:00:01 httpd 32694 ? 00:00:05 httpd 32695 ? 00:00:04 httpd 32696 ? 00:00:05 httpd 32697 ? 00:00:01 httpd 32698 ? 00:00:01 httpd 430 ? 00:00:01 httpd 1346 ? 00:00:01 httpd 1347 ? 00:00:00 httpd 1368 ? 00:00:04 httpd 1373 ? 00:00:00 httpd 1374 ? 00:00:01 httpd 11755 ? 00:00:03 httpd # # service httpd stop httpd beenden: [ OK ] # # service httpd stop httpd beenden: [ OK ] # # service httpd stop httpd beenden: [FAILED] # # ps -A | grep http [returns nothing, now] # # service httpd start httpd starten: [ OK ] # --- snapp --- FYI: "starten" means something like "start", "beenden" means "stop". Actual results / Expected results: Restart of httpd without such annoying problems after httpd relevant updates...
This looks like timing issues. But "service httpd stop" is supposed to wait for the old pid to become unusable, and the httpd parent is supposed to wait for children to exit. The parent-waiting-for-children timing is known to be broken so maybe that's the issue.
Joe, your are the Apache guy...is it possible to solve my issue?
BTW, I'm now also able to reproduce my problem at simple httpd restarts without any upgrades before (!), httpd only had to have lots of processes before :-( Any chance how to solve clean?
OK, can you try out these packages: http://people.redhat.com/jorton/devel-httpd/ This adjusts the odds such that httpd is more likely to exit within the four seconds which the init script will wait for it (this is really a fix for bug 119128). It will still be possible for the "restart" to leave a wedged server, but less likely. These packages use a new timing algorithm for reclaiming child processes - feedback from testing would be very useful.
Heyho great work, seems to work - I wasn't able to reproduce my old problem (with the same scenarios), yet. But I'll go on with testing and try to give further feedback in a week or so, again.
Seems so, that the patch didn't solve my issue really, so I got the same error (like at the top) only a few minutes at a simple httpd restart with your patched httpd again...
I'm not sure what further changes to httpd are appropriate now. It is universally true that "service xxxx restart" may fail to restart the service if it does not shut down fast enough -- that's how the "killproc" function is written, most of the init scripts use it. With the patch in FC3 to fix the child reclaim timing issue, it's now less likely that you'll hit the failure mode here with httpd, so hopefully this is enough.
Joe, I have the problem anyway using 2.0.52-3 on 2 boxes: - Intel Celeron 1.0 GHz, 512 MB RAM - Intel Xeon 3.2 GHz, 4 GB RAM both systems are running latest Fedora Core Development. Normally the load at "service httpd condrestart" goes up to 5 or even to 12 (every cron.weekly) and a "service httpd restart" also fails if httpd has enough processes visible in the process list.
So why are you not using reload or graceful if you want to ensure that httpd is still running afterwards?
Well, cron.weekly is doing condrestart per default (so the normal restart isn't really my problem any longer). But condrestart causes a higher load - at smaller systems load 12 or 15 is critical, for example sendmail rejects incoming mail connections at this time at my system :-(
I'm not sure what you mean by "per default". The only thing which happens by default is that logrotate does a graceful restart one a week; no condrestart and no restart. condrestart is equivalent to restart if httpd is already running: it stops the existing httpd, waits a bit, and then starts another one. service httpd reload and graceful are completely different: they just signal the existing httpd to re-read the configuration file and reload modules.
I think, I found the real problem causing it. If httpd is linked against db4 4.0.14 (like at RHL9), I can't reproduce the problem. Same at 4.1.25 (RHEL3). If I use db4 4.2.52 (e.g. FC3), I can reproduce the problem many times - especially using a non-threaded db4, while httpd itself was built at a threaded db4. The fine thing: Since db4 4.3.21 I can't reproduce the problem any longer :-) I'll close this bug with works for me now...