httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Signal behavior question.
Date Tue, 24 Apr 2001 19:37:44 GMT
On Tue, 24 Apr 2001, Justin Erenkrantz wrote:
> 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?

Your understanding is 100% correct.  Graceful waits for the children to
finish their current requests, graceful doesn't.  This is how Apache 1.3
worked and the signals that they used, so we don't want to break that
compatability.  I don't know how sendmail handles SIGHUP, nor do I think
it really matters.

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

We have had this discussion before.  There are going to be a lot of people
continuing to use pre-2.4 Linux, so breaking them is not an option.  We
need to support all versions of Linux with 2.0.  Granted, the
threading/signal handling is bogus in earlier versions of Linux, but the
threading support works just fine.

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

A)  Every version of Apache 2.0 has used these signals, so it does seem to

B)  We made a conscious decision a few months ago to move ALL MPMs to
SIGWINCH to match the threaded ones.

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message