Re: register runsvdir as subreaper

From: Olivier Brunel <jjk_at_jjacky.com>
Date: Thu, 2 Feb 2017 19:14:06 +0100

On Wed, 01 Feb 2017 16:48:15 +0000
"Laurent Bercot" <ska-skaware_at_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
>
Received on Thu Feb 02 2017 - 18:14:06 UTC