On Wed, 30 Jan 2002 14:13:52 -0500 Rodent of Unusual Size <[EMAIL PROTECTED]> wrote:
[...] > I think I disagree; what you're describing is, essentially, > relying on good luck, hoping for the best, and ignoring the > problem and hoping it will go away. IIRC, what Greg > observed was the children getting hung at some time t after > the parent died. (Maybe when they tried to expire gracefully?) > IMHO, if the parent process dies, something is seriously wrong, > the server condition is indeterminate, and we need to re-base > and restart. I'm with Ken here. Children depend on parent to do the job control. Child sends SIGCHLD to parent and can only exit if parent picks that signal up (waitpid() or so). If that can't be done (for a number of reasons) -- child is said to be zombie. However, parent beeing dead isn't causing it's children to go zombie, as os can detect that (SIGCHLD to non-existing process) and cleanup correctly. Anyway this doesn't seem like normal situation and might cause a lot of trouble later on... On the other hand Bill Stoddard is also right. If nothing bad happens, child can go on servicing requests, because it dies only when parent tell it to do so (or when SEGV happens, but that's other story). However under heavy load you'll have a dead server anyway (at least with prefork MPM), because you will not have new children respawning to meet the load. And if somehow children start to die for some wonky reason, that little group will shrink very fast, which gives us only a bit delayed agony. So IMHO the best solution is to have some way in which children can check if parent is ok. Maybe another field (frequently filled up by daddy) in scoreboard? Anyway when child is sure to be orphaned, it can yeld about that in error_log. If such a message will be written with every request -- it will probably get noticed fast. The rest is up to admin: either he/she decides to fix up things or go on with that strange situation until people stop shopping :)) -- Jacek Prucia 7bulls.com S.A.
