httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: [PATCH] worker MPM, stranded processes after apachectl stop
Date Mon, 29 Nov 2004 23:41:36 GMT
Jeff Trawick wrote:

>               As soon as the
> new child takes over the process slot, the MPM forgets that the old
> child existed.  If the old child never exits on its own (long-running
> or hung request), then when Apache is terminated the old child will
> still hang around (parent pid -> 1) and will have to be killed
> manually.
> The MPM could potentially blow away forgotten children by sending
> signals to the process group (wait until the normal termination
> sequence is done, then blow away any processes we've forgotten about).

we talked about this off-list.  This option seems attractive to me because it 
doesn't require the care and feeding of new data structures.  Are you aware of 
any potential pitfalls with this approach?

> We could rework the scoreboard design to allow the maximum number of
> child processes to be represented in the scoreboard directly, though
> that may require module changes and potentially an access protocol to
> allow thread entries to be moved from one process to another without
> crashing any code accessing the scoreboard.

sounds potentially disruptive, at least for stable releases.

> We could add the pid to every worker thread entry in the scoreboard,
> then ap_reclaim_child_processes() could use that field to search for
> processes that no longer have a process slot but still have active
> threads.

simple, but more memory.  At first I was thinking that this might introduce new 
headaches relating to who can update the worker thread entry.  But that must be 
fairly well sorted out already or we'd see related bug reports.

> In the attached patch I took a different path -- explicitly maintain a
> list of processes which no longer have a process slot in the
> scoreboard.  ap_reclaim_child_processes() treats these
> otherwise-forgotten processes just like the ones which are lucky
> enough to have process slots in the scoreboard.  Before making some
> minor tweaks it *seemed to work*, but detailed testing hasn't been
> done.  At this point I'm curious to hear comments on the design.

If we can't get by with sending signals to the process group, this seems like a 
reasonable approach.  The patch looks good (invoking the "eyeball" utility, but 
not tested).


View raw message