> > This goes a ways towards getting SIGWINCH and SIGHUP to do something.
> >
> > 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.
>
> > With this patch, SIGWINCH and SIGHUP basically work for me on a
> > particular machine :)
>
> Does SIGHUP actually do a graceless shutdown on a heavily loaded machine?
>
> > There are surely other issues. I didn't understand Ryan's changes to
> > prefork signalling when he added the pod (other than the fact that
> > SIGHUP and SIGWINCH no longer caused a restart) so I don't feel to bad
> > about still being in the dark.
> >
> > I don't currently know how to proceed further with this until there is
> > some agreement about how a non-graceful restart will be implemented.
>
> 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.
>
Yep, that sounds about right. Code up a hack to put one of your child processes into
a
loop then try a graceless shutdown. If it shutsdown, then you have it.
Bill
