On Fri, 29 May 2009, Jared Johnson wrote:
What's orphaned is not a child process, but a shared mem hash record for a
process which no longer exists. I suspect that code is racy.
Hrm, then if we're getting a whole lot of these, does this mean child
processes are going away at a high rate?
Perhaps. Would need further analysis.
I think we already established a little while ago that lifetime of
pre-forked child processes is cut short by any plugin which does a
disconnect. That would lead to premature child death, but wouldn't by
itself be a race.
What I suspect is that there is a backlog of sigchild processing while the
shared mem is locked (or perhaps missed sigchild). I haven't looked in
great detail at the code, but I think the race would be removed by the
child itself removing its entry in the shared mem hash. A dying child
would be blocked waiting for the lock until the parent had finished its
!kill(0, $pid) loop.
I wouldn't expect such a condition
using prefork with relatively low concurrency, maybe this reflects a problem
during the end of the connection..
-Jared
Inbound and outbound email scanned for spam and viruses by the
DoubleCheck Email Manager v5: http://www.doublecheckemail.com
Do we have to be exposed to this spam?
