[adrusi]

I had a hell of a time a few months ago debugging why my child processes were dying, before learning that PDEATHSIG=9 (don't ask) kills child processes when the thread that created them in the parent process exits.

My debugging was not aided by the fact that disabling the code where I set PDEATHSIG had no effect, since someone else's code was invisibly setting it regardless.

[gwright]

I'm a little rusty here, but I think you are talking about the fact that the exit status of the child process has to remain available until the parent process can reap it. Until that happens the child process is in the zombie state. You indicated that the creating thread needed to exit, but that seemed a bit too specific to me, I think that any thread can reap the exit status of a child process.

Related to this is the double-fork pattern to avoid zombie processes (and a couple other issues) when initiating a daemon process.

[adrusi]

The surprising behavior was that the child process received the configured signal not when the process that created it exited, but rather when the specific thread that called fork(2) exited.

The parent process was an event loop based python program whose main function was to manage the creation and deletion of these child processes, and the simplest way to spawn child processes without blocking the event loop is to call fork(2) on a thread pool. My thread pool was triaging the number of worker threads based on demand, so occasionally it would decide a worker was no longer needed, and all the child processes that happened to have been created on that thread would get SIGKILL'd — something you rarely want when using a thread pool!

I didn't want the child processes to die unless the parent process's business logic decided they were no longer needed, or if the parent was itself killed (this latter reason being the motivation for setting PDEATHSIG).

Once I understood why my processes were dying, the solution was simple: make sure the worker threads never exit.

[gwright]

Well that certainly seems unexpected.

[ykonstant]

Jesus Christ.

[jcranmer]

No, what they're talking about is the fact that in Linux, sometimes "process" in the documentation actually means "thread", and this is particularly true if you're doing mildly funky process management APIs.