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.
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
Received on Fri Feb 03 2017 - 15:17:26 UTC
