httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodent of Unusual Size <Ken.C...@Golux.Com>
Subject Re: Parent death should force children suttee
Date Wed, 30 Jan 2002 19:13:52 GMT
Bill Stoddard wrote:
> 
> > If the parent dies, shouldn't the children get the equivalent
> > of SIGPIPE on the pod?  However they find out, they should react
> > appropriately -- i.e., by committing suicide with extreme prejudice.
> 
> -1 in concept. We should not take the child processes down if
> the parent process dies a horrible unplanned death. The way it
> is now, the sysadmin can at least set MaxRequestsPerChild to 0
> and keep child processes up to handle requests.

That needs to be done before [re]starting, however.  Once the
parent is dead, there's no way to control the children short
of directly signalling them -- which we have formally decried
for years.  And if the directive isn't set before the children
were created, you can't tell them to use the new value. :-)
Setting MaxRequestsPerChild to avoid this is a bogus band-aid.

> I know of at least one case where a big site running Apache on
> Solaris occasionally has the parent process die (funny enough,
> I only see this on Solaris with 1.3). The problem happens so
> infrequently, that it is difficult to debug. So far, it is
> impossible to reliably recreate. If we caused the entire site
> to go down when the parent dies, the owners of this big site
> would be, umm, upset, to say the least. As it is, the sys admin
> has a little time to identify that the parent has died and
> properly recycle the server.

I think I disagree; what you're describing is, essentially,
relying on good luck, hoping for the best, and ignoring the
problem and hoping it will go away.  IIRC, what Greg
observed was the children getting hung at some time t after
the parent died.  (Maybe when they tried to expire gracefully?)
IMHO, if the parent process dies, something is seriously wrong,
the server condition is indeterminate, and we need to re-base
and restart.

Consider this:  Suppose that site had an automatic monitor that
detected when the main Apache process died.  If the children
reliably died as well, it could simply restart the server, or
page someone to do it, or the like.  If the children DON'T die
automatically, something or someone has to do a manual
search-and-destroy on them before the server can be restarted.

> For the most part, the people hitting the site never know
> anything went wrong. And that's the way it should be.

I agree with the sentiment, but leaving the children running
uncontrollably after the parent has died is not an option I
consider viable.

What precedents are there?  What happens to inetd-started sessions
if inetd dies, for instance?
> 
> Bill

-- 
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist      http://Apache-Server.Com/

"Millenium hand and shrimp!"

Mime
View raw message