httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: [PATCH] screw up prefork even more
Date Thu, 14 Jun 2001 16:12:12 GMT

> > > I'm pretty sure that Ryan disagrees with the path I took for SIGHUP,
> > > which is to kill everybody we can with the pod (since that is the most
> > > clean and reliable mechanism we have) and let
> > > ap_reclaim_child_processes() handle the stragglers.
> >
> > You can't use the pod to gracelessly shutdown the child processes.  It
> > doesn't do that.  The pod will only work for graceful shutdowns.
> that's sort of what I said...  we start off like graceful (everybody
> that dies from the pod dies cleanly) and then
> ap_reclaim_child_processes() knocks everybody else out with SIGTERM

If we are going to end up sending the SIGTERM, then why bother with the
pod at all?

> > There are only two options for gracelessly killing a child process, that I
> > know of.
> >
> > 1)  Use signals.
> >
> > 2)  Have a thread that is specifically used to listen for some other
> > out-of-band communication.
> >
> > Since we are in an MPM that doesn't have threads, signals are the only way
> > I know of to implement a graceless shutdown.  The pod will not be able to
> > do this.
> by the way... what are you thinking about w.r.t. threads?

I am thinking of doing exactly what we do in threaded, namely a single
signal handling thread that does what is required to handle the kill

> One thing I wanted to avoid was having a SIGHUP handler in the server
> process which calls clean_child_exit(), because we have no idea what
> mutexes we were holding before being interrupted by a signal.  We ran
> into this previously with threaded, and though prefork should have
> less chance of this problem we don't know what libc and plugin modules
> will be doing.

Why didn't we ever see this problem in 1.3?

> For graceless shutdown I'm inserting a first step which gets
> some of the server processes out of the way before I do what I'm
> afraid of.  (Yeah, this doesn't make much sense in terms of a 100%
> solution.  It is more a way to minimize risk.)
> Did you want the SIGHUP handler in the child process to be just_die()?

It has to be.  IMNSHO, please_die_gracefully should just go away.  That
is all handled by the pod.  I just did a simple search through prefork,
and our signals are still really screwed up.   :-(

This should be relatively simple for the child process, IMO:

SIGWINCH		use pod
SIGTERM			just_die

For the parent, it gets a bit more complex

SIGWINCH		use pod to send message to child
SIGHUP			use pod to send message to child
SIGTERM			send signal to child process
SIGINT			if one_process, just_die
			otherwise, ignore


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

View raw message