httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: oddity w/SIGHUP (related to PR#429)
Date Mon, 21 Apr 1997 04:56:30 GMT
On Sun, 20 Apr 1997, Dean Gaudet wrote:

> 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
>   handlers
> 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.

This all makes sense.  Now that I am awake (erm... relatively speaking, of
course) I was getting an 'unable to bind to port' message which is
consistent with what you mention.

Don't have time to look at this more right now, but if I hack in a quick
handler to ignore HUPs before the start of make_child then reset it to the
proper handler at the end of the procedure if it is the parent, this
problem goes away.  After that change, the only problem I see is that I
get a 'bind: Address already in use' once in a while and the server ends
up with the parent dead and only one child around.  This appears to be due
to an old child process that isn't in the scoreboard (since if it is
reclaim_child_processes() will surely whine) not exiting with the killpg() 
at the start of standalone_main.

> 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. 
> Dean
> 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