Bug 132360 - httpd isn't clean stopped after httpd relevant updates, doesn't also startup then
httpd isn't clean stopped after httpd relevant updates, doesn't also startup ...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: httpd (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Joe Orton
:
Depends On:
Blocks: FC3Target FC4Target
  Show dependency treegraph
 
Reported: 2004-09-11 12:57 EDT by Robert Scheck
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: db-4.3.21
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-15 17:32:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2004-09-11 12:57:32 EDT
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...
Comment 1 Joe Orton 2004-09-11 15:31:15 EDT
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.
Comment 2 Robert Scheck 2004-09-11 18:32:34 EDT
Joe, your are the Apache guy...is it possible to solve my issue?
Comment 3 Robert Scheck 2004-09-14 03:15:51 EDT
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?
Comment 4 Joe Orton 2004-09-14 10:54:41 EDT
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.
Comment 5 Robert Scheck 2004-09-14 16:41:14 EDT
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.
Comment 6 Robert Scheck 2004-09-18 09:09:14 EDT
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...
Comment 7 Joe Orton 2004-11-02 11:09:14 EST
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.
Comment 8 Robert Scheck 2004-11-02 11:19:19 EST
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.
Comment 9 Joe Orton 2004-11-02 11:27:44 EST
So why are you not using reload or graceful if you want to ensure that
httpd is still running afterwards?
Comment 10 Robert Scheck 2004-11-02 11:32:00 EST
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 :-(
Comment 11 Joe Orton 2004-11-02 11:37:44 EST
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.
Comment 12 Robert Scheck 2005-01-15 17:32:14 EST
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...

Note You need to log in before you can comment on or make changes to this bug.