On Thu, 02 Feb 2017 19:30:17 +0000 "Laurent Bercot" <ska-supervis...@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 :)
