Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <005c01c1a9be$cd9e7980$38381b09@sashimi>
From: "Bill Stoddard" <bill@wstoddard.com>
To: <dev@httpd.apache.org>
References: <3C58232C.FE91F19F@Golux.Com>
Subject: Re: Parent death should force children suttee
Date: Wed, 30 Jan 2002 13:49:03 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


> >From something that happened a couple of days ago on Daedalus..
> The parent died, but the children hung around.  That shouldn't
> happen, and is a showstopper (but I'm not listing it as one
> yet in case I'm missing something).
Yea I agree this is a showstopper...

> 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.

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.
For the most part, the people hitting the site never know anything went wrong. And that's
the way it should be.

Bill