Mixture of signals and pipe_of_death

[rb...@covalent.net]

I thoroughly dislike the current shutdown/restart process.  We have two
different paths to shutdown or restart the server.  The first is to send a
character over a pipe, which tells the child processes to gracefully
restart or shutdown.  The second is to send a signal to the child
processes to tell them to ungracefully shutdown or restart.

I would really like to see us come up with one method for killing child
processes either gracefully or non-gracefully.  I'll be working on this in
the next few days/weeks.

Ryan


_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: Mixture of signals and pipe_of_death

[Manoj Kasichainula <ma...@io.com>]

On Sun, Apr 30, 2000 at 03:05:23PM -0400, rbb@covalent.net wrote:
> 
> > The only way to do a true immediate ungraceful shutdown of a child is
> > to send a signal, because you have to interrupt system calls.
> 
> That's not true.  If the child process is really going to die, then all we
> need to do is run the child_exit stuff, destroy all the pools, and
> exit.  The rest of the threads will die automatically.

Well, you have to have a way to wake up a thread that's busy so it can
notice the bytes on the pipe. Unless you retain a thread that does
nothing but listen to it.

> Well, the way I would do this, is to ignore the pipe, and use a unix
> domain socket (remember this stuff is only valid for non-windows MPM's
> anyway).  The same socket is used for all parent/child
> communication.  This allows any process to send a signal to any child
> process.

You either have to have multiple unix domain sockets (one per child),
or you have to indicate pids in the messages or something.  This feels
icky, especially to deal with a boundary condition which happens
extremely rarely. And an administrator is far less likely know know
how to compose a "kill this child" message for the socket when a
process is running away.

I don't see any real gain from this. -0.

> > It would be nice to eliminate ungraceful restart though. I don't think
> > ungraceful shutdown in the children is trustworthy right now, so its
> > use should be discouraged. Users who need it can kill -TERM and then
> > restart. A side benefit of this would be to give us back the HUP
> > signal, so we don't have this icky SIGUSR1/SIGWINCH problem.
> 
> I have not problem with getting rid of ungraceful restart as long as we
> keep ungraceful shutdown.  Restart could be added back the same way Linux
> rc.d does ungraceful restart, in a script shutdown and start it up again.

Exactly. :)

Re: Mixture of signals and pipe_of_death

[rb...@covalent.net]

> The only way to do a true immediate ungraceful shutdown of a child is
> to send a signal, because you have to interrupt system calls.

That's not true.  If the child process is really going to die, then all we
need to do is run the child_exit stuff, destroy all the pools, and
exit.  The rest of the threads will die automatically.

> 
> I guess you could replace the sigwait thread with a thread that reads
> on another pipe. But, I think it's good to support the signalled
> mechanism anyway; if a child process is running away, the
> administrator should be able to shut it down.

Well, the way I would do this, is to ignore the pipe, and use a unix
domain socket (remember this stuff is only valid for non-windows MPM's
anyway).  The same socket is used for all parent/child
communication.  This allows any process to send a signal to any child
process.

> 
> It would be nice to eliminate ungraceful restart though. I don't think
> ungraceful shutdown in the children is trustworthy right now, so its
> use should be discouraged. Users who need it can kill -TERM and then
> restart. A side benefit of this would be to give us back the HUP
> signal, so we don't have this icky SIGUSR1/SIGWINCH problem.

I have not problem with getting rid of ungraceful restart as long as we
keep ungraceful shutdown.  Restart could be added back the same way Linux
rc.d does ungraceful restart, in a script shutdown and start it up again.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: Mixture of signals and pipe_of_death

[Manoj Kasichainula <ma...@io.com>]

On Sun, Apr 30, 2000 at 08:24:05AM -0400, rbb@covalent.net wrote:
> 
> I thoroughly dislike the current shutdown/restart process.  We have two
> different paths to shutdown or restart the server.  The first is to send a
> character over a pipe, which tells the child processes to gracefully
> restart or shutdown.  The second is to send a signal to the child
> processes to tell them to ungracefully shutdown or restart.
> 
> I would really like to see us come up with one method for killing child
> processes either gracefully or non-gracefully.  I'll be working on this in
> the next few days/weeks.

The only way to do a true immediate ungraceful shutdown of a child is
to send a signal, because you have to interrupt system calls.

I guess you could replace the sigwait thread with a thread that reads
on another pipe. But, I think it's good to support the signalled
mechanism anyway; if a child process is running away, the
administrator should be able to shut it down.

It would be nice to eliminate ungraceful restart though. I don't think
ungraceful shutdown in the children is trustworthy right now, so its
use should be discouraged. Users who need it can kill -TERM and then
restart. A side benefit of this would be to give us back the HUP
signal, so we don't have this icky SIGUSR1/SIGWINCH problem.