On Mon, Apr 23, 2001 at 12:26:23PM -0700, [EMAIL PROTECTED] 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
