httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <>
Subject SIGUSR1 (was Re: 1.2b1)
Date Mon, 18 Nov 1996 18:34:51 GMT
On Mon, 18 Nov 1996, Dirk.vanGulik wrote:
> Somebody else wrote:
> > 	SIGUSR1/graceful restarts 
> > 	Problem: Under FreeBSD, this is lethal. USR1 followed by HUP takes down
> > 	te server. Paul S (?) reported annoying processes after a USR1.
> Could you get me more details; I cannot reproduce this on FreeBSD current and 1.1.

I'm not sure whether the USR1-followed-by-HUP issue is a problem anymore.
I'll have a mode detailed look this evening. A lot of the USR1 code is
different depending on whether you are using Listens rather than
BindAddress/nothing, so it might only affect one or the other.

The other problem I've noticed is that when you USR1 your process, the new
children get created while the old ones are still in their mutex wait. 
This is the desired behaviour. When the OS wakes one of the old children
it will process the request, then die. However this can mean that a
request after the USR1 still gets the old behaviour. More importantly, on
the systems I've tried (IRIX & Linux) the kernel seems to prefer sending
new requests to the _new_ children, so the old ones never get a chance to
kill themselves. Thus a request at some time in the future (long after the
USR1) could get an old child. Or after many USR1 signals you can end up
with a proc table full of old children. 

One solution is to have a timeout on the mutex wait, which when activated
does a generate check and either exit's or return's (back to the wait). 
Since flock or fcntl doesn't have a timeout, you need to use an alarm
instead. Incidently systems which don't use mutex can have a timeout on
the select() which is easy to implement.

Paul Sutton, UK Web Ltd

View raw message