GNOME Bugzilla – Bug 762164
GSubprocess: add API to reliably kill descendant sub-process tree
Last modified: 2018-05-24 18:33:08 UTC
When spawning a process using GSubprocess or GSubprocessLauncher, it would be convenient if we could reliably kill all of the descendant processes. One example would be to spawn `make', and then call g_subprocess_force_exit() on the make subprocess. It will not actually stop the `make' processes running, because they are all descendants of the make that was spawned. One way to work around this, at least on Linux (and probably BSD), is to call `setsid(3p)` in the child setup function, and then kill the process tree with kill(-pid, SIGKILL). However there are side effects to this, like the children continuing to run when the parent exits. Even prctl for PR_SET_PDEATHSIG isn't enough here as it would only kill the session leader. So, to avoid having to discover the "right" way to do this in every application, I think it makes sense to add API for this to GSubprocessLauncher. On Linux, it might use cgroups. On BSD, we might be stuck with setsid() and kill(-pid, SIGKILL), and who knows on Windows. But I'd love some feedback and possible API suggestions. I'd be willing to implement it if need be.
Really you want to use full containers (pid namespaces, etc.) That said I bet one could implement this today with using PR_SET_CHILD_SUBREAPER - if the first child dies, loop and kill all children that get reparented to you, then exit after a few seconds of idle (yes racy, but hard to fix without pid namespaces or cgroup access).
I agree that this would be a pretty nice feature, but I'm not sure about the implementation. As far as I know, it is not possible for non-root to change the cgroup of a process on Linux without going through some kind of intermediary via (for example) D-Bus. I'm not really interested in doing that... There is also no way to kill all processes in a cgroup, from what I understand. You rather have to list the processes that are in a cgroup and kill them one at a time, hoping that they don't fork() in the meantime. A common trick (again, as I understand it) is to freeze the processes by using the CPU cgroup to ensure that they get scheduled on no CPUs, but again, I don't think non-root can do this. Does anyone know more about this?
I hope this API would work reliably *even if the parent process is SIGKILLed*
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1135.