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. If that ability floats your boat, there's a perfectly wonderful init system that does that: Systemd. As far as the visually pleasing pstree, I'd rather have a messy pstree and simple, robust architecture than an aesthetically beautiful pstree and entangled, messy architecture. > > 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. Hey, I've heard of this great new init system that's all about cgroups! > > And even if you can, that still doesn't mean you should. Nohup is a > thing. I use it all the time, and half the time pipe its output to /dev/null. I doublefork a lot too. When I make a shellscript or design software, I never depend on the getty or terminal emulator's close closing my software. If I want it closed, I make it close itself. > People may want to leave background processes running after > they log off. Yes! Talk to any tmux user about this. I'd rather have a few orphans and zombies hanging around than foreclose the user's ability to start working from one computer and finish working at one 30 miles away, having logged out of the first one. I don't understand this desire some folks have to implement the marketing points of systemd. Visually pleasing pstree? Logging out kills all processes started during that login? What next, socket activation? Keyless remote with magnesium paddle shifter? In the features vs simplicity tradeoff, why do so few value simplicity? Runit, which I use every day, is so simple I could create a clone of it after reviewing djb's supervisor backgrounding code for about 10 minutes, and Gerrit, this isn't an insult to runit, it's a huge compliment. Runit's enough for me, but for the person wanting more USEFUL features and a guarantee against having an incommunicative, childless PID1, there's s6. And although not on-topic for a supervisor mailing list, Epoch provides wonderful init features in a very simple package. Every time I hear people wanting inits to do more, my question is "why does it have to be done in the init?" Whatever you want to do, there are a million ways to do it, so it's not necessarily the responsibility of already-written, highly functioning software. SteveT Steve Litt January 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust