On Thu, 02 Feb 2017 19:30:17 +0000
"Laurent Bercot" <ska-supervision_at_skarnet.org> wrote:
> >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.
No atomic signal sending syscall no, so it is imperfect yes, but one can
find children and send a signal to them. At least in my case, it helps
cleaning things that would otherwise stay around while I don't wish for
them to.
> 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.
Sure, and I wouldn't do that for everything, but for gettys (where
graphical sessions will be started) & my use case, I find it pretty
nice.
> >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
Of course that's due to s6-supervise reaping unknown zombies, and I am
thankful it works as it does yes :)
Received on Thu Feb 02 2017 - 20:08:16 UTC
