On Mon, 29 Nov 2004 18:41:36 -0500, Greg Ames <[EMAIL PROTECTED]> wrote: > 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?
Practical concern: killpg(0, SIGKILL) will kill the caller too, yet we need to use SIGKILL to really make sure child processes are gone; it seems we would have to create another process group to segregate the MPM child processes appropriately???? I thought Apache 1.3 did this, but not really; it does send some signals to the entire process group when shutdown starts to tell everybody to go away, but it does SIGKILL explicitly to specific child processes. abstract stuff: It bothers me that there would be two different mechanisms for terminating the MPM's child processes, one of which rarely takes effect. (Yes, I guess this "two different ways" bothers me more than "two different ways to track MPM child processes". Sucky :( ) It bothers me that we wouldn't report stubborn children to the error log.
