I have a funny feeling that there's a default handler for SIGCHLD on some platforms that kills the children. Reading the fork(3) manpage, though, indicates that children remain zombies after their deaths until the parent asks for their exit status / return code. The implication is that if the parent is already dead, then the children are caught in zombie limbo.
In any event, I'm only planning on writing the parent pid to the pidfile. This is simple enough that I am comfortable to slip it in as a handler for a common '-p pidfile' option. Anything more complicated is not appropriate right now. As with the other changes I'm arguing in favor of before the release, having an option for '-p pidfile' is an important usability and user interface issue. If it so happen that we leave a bunch of zombie children on platforms which don't have good default SIGCHLD handlers, we can consider it a bug and write the code that may be required to prevent the problem for a point release. Since we don't know what platforms will exhibit this problem, there may simply be no way to figure it out until there are a few bug reports. Sad but true :-| Aaron Blake Mitchell <[EMAIL PROTECTED]> said: > Strange, on my 2.0 setup, if I kill the parent, all the children die. > > Aaron Stone wrote: > > >Ok, we're both wrong. Children do have to be killed individually, and so the > >pids do all need to be recorded. [snip] > > > > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
