5 ms·
> PR_SET_PDEATHSIG automatically kills your children if you die, but unfortunately doesn’t extend to their descendants It indirectly does, unless you unset it
by eqvinox 2y ago
> PR_SET_PDEATHSIG automatically kills your children if you die, but unfortunately doesn’t extend to their descendants
It indirectly does, unless you unset it the child dying will trigger another run of PDEATHSIG on the grandchildren, and so on. (The setting is retained across forks, as shown in the original article.)
- skissane 2y ago> The setting is retained across forks, as shown in the original article That’s not what the man page says: > The parent-death signal setting is cleared for the child of a fork(2). https://man7.org/linux/man-pages/man2/pr_set_pdeathsig.2const.html https://man7.org/linux/man-pages/man2/pr_set_pdeathsig.2cons... Unless the man page is wrong?
- zokier 2y agoI wonder if this is difference between libc fork (which calls clone syscall) and kernel fork syscall.
- kobzol 2y agoIt is sadly not propagated to grandchildren. I tries the subreaper approach, but it doesn't help. The children are reparented to the worker, but when the worker dies, they are then just reparented to init, like normally.
- TheDong 2y agoYou also need to specifically have the subreaper process call the "wait" syscall, and wait for all children, otherwise of course they'll end up reparented to init. If you want to write a process manager, one of the process manager's responsibilities is waiting on its children.
- ComputerGuru 2y agoJust a nitpick: They don’t get reparented to init regardless of whether you call wait or not, so long as the parent process exists. They’ll be in a zombie state waiting to be reaped via a parent call to wait. Only if the parent dies/exits without reaping will they be reparented to init.