httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Hess <>
Subject Re: [PATCH] bringing down the server from an MPM thread
Date Thu, 03 Aug 2000 21:46:21 GMT
It would seem that the appropriate action would be for the child to signal
a problem, and then the parent to double-check the problem - or, for the
parent to run a poll() on all of the listen sockets before spinning up a
new child.  Perhaps the double-check code can run only when the child
didn't service any requests before exitting (though it shouldn't be
expensive enough to warrant that).

I'm also less than comfortable with having the child manage to kill the
parent.  Since the parent runs as root, and the child runs as nobody, it's
a potential security hole.  Convincing the OS to screw the listen socket
is hopefully much harder than convincing an Apache child to return a
server-should-exit code.


On 26 Jul 2000, Jeff Trawick wrote:
> The example problem I'm trying to solve now:
> Currently, when I stop the the TCP/IP stack on OS/390 and Apache starts
> getting errors from poll() and accept(), it tries to keep going,
> consuming lots of CPU because poll() and accept() return immediately
> with failure.  Listening sockets are toast and can never be used
> successfully again, and we need to clear out.  Just exiting the child
> process doesn't improve anything; it just gets the parent to fork()
> again (unless it gets the magic exit status).
> Even if the suggestion described in the ENETDOWN comment was
> implemented, worker threads would have to do something to cause the
> child processes to be exited in a way that told the parent process to
> bring down any remaining children and back up to a certain part of
> initialization, perhaps retrying the initialization of listening
> sockets until it worked again.

View raw message