On Wed, 01 Feb 2017 16:48:15 +0000 "Laurent Bercot" <ska-skaw...@skarnet.org> wrote:
(...) > You want a clean process tree with a visually pleasing "ps afuxww" > output? Fix your services so they don't leave orphans in the first There's also the possible case of having this for getty/login session. So any process spawned from there won't be reparented to PID1 but to e.g. the session's supervisor; That can include things such as pulseaudio, settings daemon, dbus, window manager, etc Also besides the visually pleasing pstree, it means one can - thanks to a finish script - ensure that upon logout everything gets killed before a new getty is respawned. > place. Is that impossible? Use process groups to identify what service > the orphans were originally spawned from: if needed, you can send a So now you're not solving the original need of making a nice pstree; Not to mention in the case mention above there will be new process groups created, so that's not applicable. > signal to the whole process group, and it will reach all the processes > in the service, including orphans. > Reparenting orphans to anything else than the default is a backwards > way to solve a nonexistent problem. Except maybe for people who want a clean process tree as you originally mentioned. Also, it was needed for containers (or pid namespace that is), where you certainly don't want to see orphans disappear from the container/pid namespace as they get reparented to the "main" PID1. For PID1 inside a new pid ns to be a PID1, it needs to be a subreaper. Having the ability to make other processes subreapers as well/without the need to be PID1 in a new pid ns can be nice. As much as you may dislike it, my s6-supervise processes are subreapers, svscan's children can only be supervisors, anything else will remain under its supervisor, and I like it :) > Note that s6 will work in containers, for instance with s6-overlay > as John mentioned. Unlike runit, it also allows you to customize what > it does on receipt of a SIGTERM. > > -- > Laurent >