>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
Those are more examples of what you *can* do, with no precise reason
why you *should*.
http://e.lvme.me/u33yl35.jpg
>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.
How would you do that? Unless the subreaper comes with yet another
system call to genocide all its children, you still need some mechanism
to atomically send a signal to everything - which means you want to
have everything into the same process group (which is unlikely if you
have an interactive session), or you need cgroups.
And even if you can, that still doesn't mean you should. Nohup is a
thing. People may want to leave background processes running after they
log off. The current mechanism of SIGHUPping everything when the session
ends works, and can be ignored when needed - sounds perfect to me.
>So now you're not solving the original need of making a nice pstree;
I question the importance of that "need" when balanced against the cost
of system lock-in - this cost is invisible, which is why most people
happily ignore it, but it's there nonetheless.
>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.
Oh, definitely, but making the "new" pid1 a reaper could just be done
by the kernel at unshare time, without a separate entry point.
>Having the ability to make other processes subreapers as well/without
>the need to be PID1 in a new pid ns can be nice.
I guess this is just a matter of opinion at this point, but I disagree
-
I think this ability does more harm than good.
>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 :)
You can only do that because s6-supervise correctly handles children
it does not know it has. Be thankful the code is liberal in what it
accepts, even when I disagree with the idea. :P
--
Laurent
Received on Thu Feb 02 2017 - 19:30:17 UTC
