6 ms·

Does anybody know if the functionality mentioned in the "One final note" — having all children, grandchildren, great-grandchildren, etc. of a designated "main"

Does anybody know if the functionality mentioned in the "One final note" — having all children, grandchildren, great-grandchildren, etc. of a designated "main" process reliably terminated when that "main" process terminates — is available via something more lightweight than the containers? Traditional process groups/sessions are laughably inappropriate for this purpose since breaking out of them is trivial and in fact, about half of applications that internally use worker (sub)processes do exactly that, in order to (re)implement their own job control.

yrro 5y ago
Interesting idea. A sort of PR_SET_CHILD_SUBREAPER + "if I die, send SIGKILL to all my children" option. That would be handy...
- Joker_vD 5y ago
  Technically, it could be implemented if the subreaper process were getting notified somehow of new processes being reparented to it. Alas, subreapers don't get such notifications. Also, you need some protection against children who do "kill(-getpid(), SIGKILL)" before the exit.
paulfurtado 5y ago
If running as a privileged user, you can run the process in just a PID namespace with no other container features enabled using the unshare command. Systemd can also handle it by killing the processes by cgroup i believe, and for non services you could take advantage of that with systemd-run.
- Joker_vD 5y ago
  Are these things properly "nested"? Imagine a scenario like this: A process is started with "unshare A" or "cgexec A" or whatever, then it creates children one of which does "unshare B" or "cgexec B", then the first process, "A", is killed, or its cgroup is signalled, whatever. Will the process "B", that was put into a new namespace/cgroup, be terminated too or not? With traditional pgroups/sessions the answer is "no", and I'd like it to be "yes", so no runaway processes should be possible. I personally think the only way to make a "detached" process should be by asking some process from an entirely different "group" (over RPC, presumably) to launch something for you: so that the newly created process would technically be a children of this other "launcher" process.

yrro 5y ago

Interesting idea. A sort of PR_SET_CHILD_SUBREAPER + "if I die, send SIGKILL to all my children" option. That would be handy...

Joker_vD 5y ago
Technically, it could be implemented if the subreaper process were getting notified somehow of new processes being reparented to it. Alas, subreapers don't get such notifications. Also, you need some protection against children who do "kill(-getpid(), SIGKILL)" before the exit.

paulfurtado 5y ago

If running as a privileged user, you can run the process in just a PID namespace with no other container features enabled using the unshare command. Systemd can also handle it by killing the processes by cgroup i believe, and for non services you could take advantage of that with systemd-run.

Joker_vD 5y ago
Are these things properly "nested"? Imagine a scenario like this: A process is started with "unshare A" or "cgexec A" or whatever, then it creates children one of which does "unshare B" or "cgexec B", then the first process, "A", is killed, or its cgroup is signalled, whatever. Will the process "B", that was put into a new namespace/cgroup, be terminated too or not? With traditional pgroups/sessions the answer is "no", and I'd like it to be "yes", so no runaway processes should be possible. I personally think the only way to make a "detached" process should be by asking some process from an entirely different "group" (over RPC, presumably) to launch something for you: so that the newly created process would technically be a children of this other "launcher" process.