You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Paul J. Reder" <re...@raleigh.ibm.com> on 2001/04/23 18:42:47 UTC
Signal behavior question.
In putting the signal function back into prefork, I must rewrite it some
because it was part of the reason for the deadlock (hence the removal).
The code that replaced it was too genteel in its handling of some of the
signals (hence the request to rewrite them).
I wanted to verify my understanding of the signals so that I can implement
and test them accordingly.
SIGTERM - shutdown ungracefully.
SIGINT - shutdown ungracefully.
SIGQUIT - shutdown gracefully (no restart)?
SIGHUP - shutdown gracefully and restart.
SIGWINCH - shutdown gracefully and restart.
SIGSEGV, SIGBUS, SIGABORT, SIGABRT, SIGILL should all dump core and exit ungracefully.
SIGXCPU and SIGXFSZ should go to the default handler.
SIGPIPE should be ignored.
Do I have all of these right? Have I missed any?
Thanks,
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Signal behavior question.
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> A) Every version of Apache 2.0 has used these signals, so it does seem to
> work.
Granted -- more importantly, I wouldn't want to have to change every site's
custom log rotation script just because we changed the signals.
> B) We made a conscious decision a few months ago to move ALL MPMs to
> SIGWINCH to match the threaded ones.
*shrug* It was a lot more than a few months ago. Was there some reason
that it was hardcoded instead of being configurable?
....Roy
Re: Signal behavior question.
Posted by rb...@covalent.net.
On Tue, 24 Apr 2001, Justin Erenkrantz wrote:
> On Mon, Apr 23, 2001 at 12:26:23PM -0700, rbb@covalent.net 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
work.
B) We made a conscious decision a few months ago to move ALL MPMs to
SIGWINCH to match the threaded ones.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Signal behavior question.
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Apr 23, 2001 at 12:26:23PM -0700, rbb@covalent.net 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
Re: Signal behavior question.
Posted by rb...@covalent.net.
> > IMHO, this is too complex. I would suggest viewing it this way:
> >
> > PARENT CHILD
> >
> > shutdown
> > gracefull SIGHUP SIGWINCH
> > ungracefull SIGKILL SIGTERM
> > (may want to add another to ungracefully shutdown, so that we
> > cleanup correctly.)
> >
> > restart
> > gracefull SIGWINCH
> > ungracefull SIGTERM
>
> I agree with you on the fact that the child can only be shutdown.
> The parent should only be concerned handling the restarts.
>
> Isn't SIGHUP a graceful restart? SIGTERM should be a graceful shutdown.
> Don't know what a SIGWINCH should do as I've never used it.
>
> Just checking... -- justin
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.
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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Signal behavior question.
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Apr 23, 2001 at 10:26:42AM -0700, rbb@covalent.net wrote:
>
> IMHO, this is too complex. I would suggest viewing it this way:
>
> PARENT CHILD
>
> shutdown
> gracefull SIGHUP SIGWINCH
> ungracefull SIGKILL SIGTERM
> (may want to add another to ungracefully shutdown, so that we
> cleanup correctly.)
>
> restart
> gracefull SIGWINCH
> ungracefull SIGTERM
I agree with you on the fact that the child can only be shutdown.
The parent should only be concerned handling the restarts.
Isn't SIGHUP a graceful restart? SIGTERM should be a graceful shutdown.
Don't know what a SIGWINCH should do as I've never used it.
Just checking... -- justin
Re: Signal behavior question.
Posted by rb...@covalent.net.
IMHO, this is too complex. I would suggest viewing it this way:
PARENT CHILD
shutdown
gracefull SIGHUP SIGWINCH
ungracefull SIGKILL SIGTERM
(may want to add another to ungracefully shutdown, so that we
cleanup correctly.)
restart
gracefull SIGWINCH
ungracefull SIGTERM
As far as child processes are concerned, they only ever shutdown. The
parent should translate the four threads they can receive into the two
that children understand.
If we are executing in single-user mode, then the child process should
also handle SIGINT for a graceless shutdown.
All other signals should be ignored, except for SIGABORT and SIGABRT,
which should force a core dump.
Ryan
On Mon, 23 Apr 2001, Paul J. Reder wrote:
> In putting the signal function back into prefork, I must rewrite it some
> because it was part of the reason for the deadlock (hence the removal).
>
> The code that replaced it was too genteel in its handling of some of the
> signals (hence the request to rewrite them).
>
> I wanted to verify my understanding of the signals so that I can implement
> and test them accordingly.
>
> SIGTERM - shutdown ungracefully.
> SIGINT - shutdown ungracefully.
> SIGQUIT - shutdown gracefully (no restart)?
> SIGHUP - shutdown gracefully and restart.
> SIGWINCH - shutdown gracefully and restart.
>
> SIGSEGV, SIGBUS, SIGABORT, SIGABRT, SIGILL should all dump core and exit ungracefully.
>
> SIGXCPU and SIGXFSZ should go to the default handler.
>
> SIGPIPE should be ignored.
>
> Do I have all of these right? Have I missed any?
>
> Thanks,
>
> --
> Paul J. Reder
> -----------------------------------------------------------
> "The strength of the Constitution lies entirely in the determination of each
> citizen to defend it. Only if every single citizen feels duty bound to do
> his share in this defense are the constitutional rights secure."
> -- Albert Einstein
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------