On Fri, May 27, 2016 at 7:19 AM, Zbigniew Jędrzejewski-Szmek
On Fri, May 27, 2016 at 08:09:33AM -0500, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> said:
> > Also note that running jobs in a systemd service has advantages on the
> > server: better accounting, more transparency, logs are easier to read.
> > The (old) default of allowing left-over session processes to live on
> > seems especially bad on a server with multiple users.
> Starting a one-off task under screen and detaching is an age-old server
> management process. Breaking that is not acceptable IMHO.
This change was done for a reason: left-over session processes
are causing real problems.
You still can start a one-off task under screen, you just need to
invoke it in one the different ways described in
I have to agree, but there is a difference in expectations depending
on the system.
Fedora Workstation, I expect all processes launched by/owned by me, to
be quit on logout. Actually what I expect is by telling GNOME I'm
logging out, restarting, or shutting down, that it should send a quit
message to all applications. Those applications should be able to
interrupt this if there's unsaved data and prompt the user; but better
than this would be applications that can save their own state because
an application cancelling a reboot is archaic. But often this doesn't
work, processes continue to keep the user-session alive because they
won't stop running. So we keep seeing these problems on Fedora were
the system won't reboot for 1m30s which is the systemd timeout for
user sessions that haven't yet quit.
So it's a problem.
Fedora Server, I expect to login, run tmux, start sessions, detach,
and log out and I expect those tmux sessions to keep running. If this
workflow is going to change I need some super clean and obvious way to
know the right new way to do things or I'll just get annoyed and
cranky. Running tmux as a systemd service? I don't know how that'll
work, and I'm very skeptical that the user should get dinged with a
workflow change just because there are some stubborn programs floating
around that won't quit without delay.
It seems to me systemd should be able to know the difference between
a program that's zombie or unresponsive but isn't doing anything or is
unresponsive but is doing something; and if not then some way for
programs to say "hey wait just a minute, I need to clean things up" or
whatever, rather than just abruptly killing them.