Isn’t it strange what systemd has done with its latest release version 230 regarding user background process and login sessions? Or is it just me who feels so? Anyway in this post I am going to analyse this change[1] in default setting of logind.conf that upstream has released recently. Let me kick off with the following snippet taken from changelog of v230:

>>> systemd-logind will now by default terminate user processes that are part of the user session scope unit (session-XX.scope) when the user logs out. This behavior is controlled by the KillUserProcesses= setting in logind.conf, and the previous default of “no” is now changed to “yes”. This means that user sessions will be properly cleaned up after, but additional steps are necessary to allow intentionally long-running processes to survive logout. <<<

Click here for complete changes with v230 release.

So what does that mean? I can explain the above change citing the example of GNU Screen. For an average GNU/Linux user it is not an unfamiliar tool. GNU Screen is a basically a terminal multiplexer application which allows user to access different login sessions within a single terminal instance. It is really flexible in such a way that we can detach and reattach to sessions from a terminal at anytime as long as it is alive. This is really useful in scenarios where a particular remote process is required to run continuously even when the user is disconnected. One such scenarios where I have found it useful is the usage of IRC client irssi with GNU Screen to keep me connected to various channels forever. And I can only think for more with respect to GNU screen’s necessity in our daily use cases.

Now coming to the point, why did I explain it in such a detail while we have systemd in our plate for discussion? Interpreting from the changelog snippet given above it is now indeed the case that any background process that were still running are killed automatically when the user logs out of a session. Even though it is not a new feature from systemd perspective the default setting has been changed. A special parameter named KillUserProcesses from /etc/logind.conf controls this behaviour for which it defaults to ‘yes’. GNU Screen is supposed to run as background process as we can infer from its design and use cases. Obviously systemd update to v230 will break this behaviour. You can no longer start a screen (or tmux) session, log out, and expect to come back to it. Apart from setting this parameter back to ‘no’ systemd allows us to have long running processes via other ways as explained in the following part of changelog:

>>> While the user is logged in at least once, user@.service is running, and any service that should survive the end of any individual login session can be started at a user service or scope using systemd-run. systemd-run(1) man page has been extended with an example which shows how to run screen in a scope unit underneath user@.service. The same command works for tmux. <<<

>>> After the user logs out of all sessions, user@.service will be terminated too, by default, unless the user has “lingering” enabled. To effectively allow users to run long-term tasks even if they are logged out, lingering must be enabled for them. See loginctl(1) for details. The default polkit policy was modified to allow users to set lingering for themselves without authentication. <<<

>>> Previous defaults can be restored at compile time by the –without-kill-user-processes option to “configure”. <<<

We have so many GNU/Linux users initiating background processes using a screen session and almost no one will ever read through the changelog whenever an update is available. So people will be surprised to see that for the first time their background processes have been killed and eventually start blaming other things before they finally figure out the underlying systemd change. In order to workaround this change users are required to enable lingering (which I am not aware of) and starting GNU screen sessions via systemd-run which will be a great nuisance for a larger percentage of people. On the other side its worth looking at a possible distinction that systemd can do between background processes that were initiated via tty and X/Wayland login sessions. I am not a systemd expert rather a consumer in one way or other as I use Fedora for my day to day work. I believe systemd introduced this change based on some dbus related issue[2] reported via this bug.

Considering all these facts I don’t think it was a wise decision from systemd team to flip this default setting which will break user expectations to greater extent. Any way if systemd does not revert it upstream it will surely be disabled by majority of GNU/Linux distributions who have adopted systemd for managing system and services.

Useful links:
[1] Commit: https://github.com/systemd/systemd/commit/97e5530cf2076a2b4fc55755917262607aaa6338
[2] dbus bug: https://bugs.freedesktop.org/show_bug.cgi?id=94508
[3] Debian tracker bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394