An irritating systemd behavior when you tell it to reboot the system
For reasons well beyond the scope of this entry, I don't use a
graphical login program like gdm; I log in on the text console and
start X by hand through
xinit (which is sometimes annoying). When I want to log out, I cause the
X server to exit and then log out of the text console as normal.
Now, I don't know how gdm et al handle session cleanup, but for me
this always leaves some processes lingering around that just haven't
gotten the message to give up.
(Common offenders are
and its many friends. Speech-dispatcher is so irritating here that
chmod 700 the binary on my office and home machines.)
Usually the reason I'm logging out of my regular session is to
reboot my machine, and this is where systemd gets irritating. Up
through at least the Fedora 24 version of systemd, when it starts
to reboot a machine and discovers lingering user processes still
running, it will wait for them to exit. And wait. And wait more,
for at least a minute and a half based on what I've seen printed.
Only after a long timer expires will systemd send them various
signals, ending in
SIGKILL, and force them to exit.
(Based on reading manpages it seems that systemd sends user processes
no signals at all at the start of a system shutdown. Instead it
probably waits TimeoutStopSec, sends a
SIGTERM, then waits
TimeoutStopSec again before sending a
SIGKILL. If you have a
program that ignores everything short of
SIGKILL, you're going
to be waiting two timeout intervals here.)
At one level, this is not crazy behavior. Services like database engines may take some time to shut down cleanly, and you do want them to shut down cleanly if possible, so having a relatively generous timeout is okay (and the timeout can be customized). In fact, having a service have to be force-killed is (or should be) an exceptional thing and means that something has gone badly wrong. Services are supposed to have orderly shutdown procedures.
But all of that is for system services and doesn't hold for user
session processes. For a start, user sessions generally don't have
a 'stop' operation that gets run explicitly; the implicit operation
SIGHUP that all the processes should have received as the
user logged out. Next, user sessions are anarchic. They can contain
anything, not just carefully set up daemons that are explicitly
designed to shut themselves down on demand. In fact, lingering user
processes are quite likely to be badly behaved. They're also
generally considered clearly less important than system services, so
there's no good reason to give them much grace period.
In theory systemd's behavior is perhaps justifiable. In practice, its generosity with user sessions simply serves to delay system reboots or shutdowns for irritatingly long amounts of time. This isn't a new issue with systemd (the Internet is full of complaints about it), but it's one that the systemd authors have let persist for years.
(I suspect the systemd authors probably feel that the existing ways to change this behavior away from the default are sufficient. My view is that defaults matter and should not be surprising.)
When I started writing this entry I expected it to just be a grump,
but in fact it looks like you can probably fix this behavior. The
default timeout for all user units can be set in
DefaultTimeoutStopSec setting; set this down to less
than 90 seconds and you'll get a much faster timeout. However I'm
not sure if systemd will try to terminate a user scope other than
during system shutdown, so it's possible that this setting will
have other side effects. I'm tempted to try it anyways, just because
it's so irritating when I slip up and forget to carefully
all of my lingering session processes before running
Update: I'm wrong. Setting things in
user.conf does nothing
for the settings you get when you log in.
(You can also set KillUserProcesses in
but that definitely will have side effects you probably don't
even if some people are trying to deal with them anyways.)
Comments on this page: