httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [PATCH] log execve() failures
Date Fri, 14 Jul 2000 21:41:39 GMT
On Fri, Jul 14, 2000 at 01:11:33PM -0400, Greg Ames wrote:
> rbb@covalent.net wrote:
> > > >    The best thing I can suggest, is to have ap_create_process wait on
> > > > the child process before it returns.
> > >
> > > Seems kinda complex for a condition that doesn't exist today.
> > 
> > Okay, so modify mod_cgi[d].  If the child process dies, do a wait in
> > there.  This will get us the same error code.
> > 
> > We cannot write to stderr from within a library.  There are very few
> > places where we currently write to stderr in APR:
> > 
> I researched the wait approach, and IMO the cure is worse than the
> disease.  The research was educational for me though :-)  Please correct
> me if my reasoning is flawed.
> 
> Looks like we would have to change the handling of SIGCHLD so that the
> child becomes a zombie briefly, then reap the status via some kind of
> wait.  The way the code is partitioned today, it would make the most
> sense to change the SIGCHLD handling in APR, and do the wait in either
> mod_cgi(d) or util_script.  
> 
> Unfortunately that opens up the opportunity for bugs where the app
> screws up and doesn't do the wait properly, and we end up leaking zombie
> processes :-(  Plus, we would have to do the wait in the mainline path
> as well as the error path, which adds a little path length (probably not
> much compared to fork).

How about if we register a cleanup (at process creation) and do the wait
there? (to clean the zombie)  APR can then have a handy "wait for <this>
process" function which kills the cleanup. mod_cgi(d) and/or util_script can
use this new APR function, or just wait for the (request pool) cleanup.

It seems pretty straight-forward...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message