httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: oddity w/SIGHUP (related to PR#429)
Date Sun, 20 Apr 1997 23:01:19 GMT
That is weird.  Can you give it a try with my graceful patch installed?
Or just take the little hunk that adds SIGALRM to the block-mask of the
hup handler?  (It's in set_signals).

I'm going to change the graceful patch so that:

- restart and graceful_restart disable SIGHUP and SIGUSR1 immediately
- set_signals blocks SIGHUP, SIGUSR1, and SIGALRM inside the hup and usr1

It's also possible that make_child needs to ignore signals.  Oh yes, it
does.  Shoot, right after the fork the child still has restart() as its
sighup handler, and the parent will send a hup to it if it gets a hup.  Ok
I'll clean this up in my graceful patch too.

I'm not delaying 1.2 for this patch, I'm going to propose that we roll 1.2
really soon and then immediately apply a bunch of the pending patches. 
graceful still won't work for everyone, but I'm getting into some core bug
fixes in the patch. 


On Sun, 20 Apr 1997, Marc Slemko wrote:

> PR#429 brings up the issue of multiple SIGHUPs very soon after one
> another.  Not sure why the proxy affects things, but there is an
> unavoidable (while using portable signal() semantics) race condition after
> restart() is called and before it resets HUPs to be ignored.  The length
> of this race condition could be reduced by adding a signal(SIGHUP,
> SIG_IGN) at the start of restart(), but you still have the problem that
> subsequent HUPs may be ignored if they come in the wrong place.
> What I noticed that seemed odd is that if I start Apache, then do
> something like: 
> 	while true; do kill -HUP 666; done
> where 666 is the PID of the parent, eventually the parent will get a new
> PID.  I haven't had a chance to look, but I don't recall any code that
> would do this... am I crazy?  This is under FreeBSD 2.1.x.

View raw message