httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: Signal behavior question.
Date Tue, 24 Apr 2001 19:21:26 GMT
On Mon, Apr 23, 2001 at 12:26:23PM -0700, wrote:
> On Apache 1.3
> SIGHUP was a graceless restart
> SIGUSR1 was a gracefull restart
> SIGTERM was a graceless shutdown
> SIGKILL was essentiall a graceless shutdown.

Just so I am on the same page with everyone else, what should be the
difference between a graceless restart and a graceful restart?

My (un)educated guess is whether you forcibly kill all of the children 
(even if they are serving a page right now).  My impression has always
been that SIGHUP should be fairly graceful - kill all children as soon
as they are idle and any new children get the new configuration.  Don't
kill off a request mid-stream because of a new config.  That doesn't
fit my understanding of how SIGHUP is handled - what does sendmail do if
you SIGHUP it in the middle of an SMTP session?  Does it wait or does
it immediately kill the transaction?

> Apache 2.0 should have the same signals do the same thing, but SIGUSR1
> doesn't play well with threads on some older versions of Linux, so
> SIGWINCH is replacing SIGUSR1.

IIRC, this applies to Linux 2.0/2.1 (or earlier).  Linux 2.4 is now out.
(Donning flame-retardant suit.)  Is there a need to support this?  Seems 
like a lot of confusion to support an OS that is just obviously broken
with threading.  2.4 will be even more rock-solid by the time (if!) we 
release Apache 2.x (and I've been using the 2.3/2.4 series for a while 
now).  SIGWINCH may not always be used, but what about when -DNO_DETACH 
is used (i.e. debugging)?  What happens when I resize my xterm?  (I
haven't tested this.)

I know someone probably still uses Linux 2.[01], but why not have a
special #ifdef for this broken platform if they REALLY want threading
on this platform (i.e. they have to change the source code).  Everybody 
else can use SIGUSR1 for a graceful restart.  Or better yet, disable 
threading by default on Linux 2.[01].  They have two new series of 
kernels that works if they want threading without mucking around in the 
source code.

The idea of different signals on different OSes meaning different things 
does scare me - but I just think that it is so patently broken, it 
probably isn't worth changing everything because of one broken OS that
isn't even supported anymore.  

(And, thanks to mod_mbox and ht://Dig, I've read some of the previous 
threads about this - I know I'm just rehashing old ideas here - please 
excuse my naviete - but since we are mucking around with the signal
handling, it isn't the worst time to revisit this...)

If we ever get FreeBSD's threading to work (probably with some patches
going in on the FreeBSD side based on my understanding of what the
problems are), I imagine we will be doing some version specific 
configuration for FreeBSD as well (i.e. threading on FreeBSD-4.x and 
FreeBSD-5 before 20010424 - whenever the patches are committed - do not 
have threading support enabled).  

My $.02.  -- justin

View raw message