Prevent Logoff from Killing tmux Session

Question

I have noticed that a logoff (log out) from my X user session will kill any tmux session I have initiated, even sessions I had run with sudo tmux and similar commands. I am sure that this formerly did not happen, but some recent change has effected this behavior.

How do I maintain these tmux (or screen) sessions, even after I end my X session?

Solution 1

This "feature" has existed in systemd previously, but the systemd developers decided to effect a change in the default, to enable the setting for termination of child processes upon log out of a session.

You can revert this setting in your logind.conf (/etc/systemd/logind.conf):

KillUserProcesses=no

You can also run tmux with a systemd-run wrapper like the following:

systemd-run --scope --user tmux

For these systems, you may just want to alias the tmux (or screen) command:

alias tmux="systemd-run --scope --user tmux"

Solution 2

The missing bit can be found on SU:

First: Keep the $USER's SystemD instance running after logoff:

sudo loginctl enable-linger $USER

Second: Reboot. (According to man loginctl this becomes effective on the next boot only.)

Third: Start tmux under control of the $USER's SystemD instance:

systemd-run --scope --user tmux

That's it.

There is no need to change /etc/systemd/logind.conf for this.

Note:

• This is needed only for Users who are not root.
• If you start tmux directly (not via systemd-run), it get's killed.
• Hence either use an alias or a wrapper script like follows:

#!/bin/bash

[ -x /usr/bin/systemd-run ] &&
dbus-send --print-reply / org.freedesktop.DBus.Peer.Ping &&
/usr/bin/systemd-run --scope --user -- /bin/true &&
exec /usr/bin/systemd-run --scope --user -- /usr/bin/tmux "$@"
exec /usr/bin/tmux "$@"

I install this with chmod +x "$HOME/bin/tmux" to avoid edits of .bashrc which might vanish if your profile is reset.

Update: /usr/bin/systemd-run --scope --user -- /bin/true is needed to test that systemd-run is usable in ssh context while X11 is active in parallel. Here, to run permanent tmux, you apparently need to run it from X11 session, not ssh.

Update 2: Reboot is needed and linger state can be found with

ls -al /var/lib/systemd/linger

Comments

[Tim]

if you are interested, unix.stackexchange.com/questions/490243/…

[Tim]

What is "X user session" that you "logoff from"? Its process name is ...?

[Rolf]

While I don't think this is particularly handy, you could start the tmux session outside X, i.e. on tty1 as described here: unix.stackexchange.com/a/167388/67833

[palswim]

Additional discussion in a reddit thread.

[JdeBP]

… and in many other places. In the Debian bug that that refers to, I explained how one could actually make systemd-logind do the right thing. bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221

[Tim]

@JdeBP Thanks for telling us that sending SIGHUP instead of SIGTERM and SIGKILL allows daemons to survive closing of a systemd logind session. I'd also appreciate if you could also consider unix.stackexchange.com/questions/484344/… and unix.stackexchange.com/a/490435/674

[invot]

/usr/bin/systemd-run --scope --user -- /usr/bin/tmux does not work on Ubuntu 20.04 from July 2020. When I log out all Xsessions (such that the X11 service is restarted), all tmux instances vanish.

[invot]

@JdeBP even your variant seems to no more work with Ubuntu 20.04. Perhaps it's Ubuntu and not SystemD. Just a simple logout/login does no harm. I need to switch back and forth between several X11 logins and use them in parallel and then logout all together. Suddenly tmux vanishes.

[invot]

Oh well, SystemD is the culprit: kill 15 418881(tmux: server) from systemd(12762). This proof comes from stap kill.probe

[Peeyush Kushwaha]

How do I silence the "running scope as unit ...." when using the alias ?

[0xC0000022L]

Editing logind.conf basically has the same effect - but globally - as enable session lingering. You can either disable it altogether or per user. But without this setting you need to remember to enable session lingering or go through hoops like you.

[invot]

@0xC0000022L I disagree. When KillUserProcesses=no we lose the advantages of SystemD's session management, as it no more kills unintentionally hung processes on logout (which is quite common). Note that I hate SystemD because it is tremendously overpowered for that simple task of being PID 1. SystemD throws us back into the era of sendmail and then takes us all hostage there. FYI sendmail is so incredibly powerful that you rather never want to use it anymore, trust me! But if you are stuck with something like SystemD anyway, then, please, start to use all of its strength and power!

[0xC0000022L]

so make your mind up. I'm quite indifferent but for starters you assumed I was referring to that particular setting when in reality I was more thinking about KillExcludeUsers= which basically persists disabling session lingering for the given users (but really read the man page and decide yourself, I'd say). And given I have just "tasted" recently how "powerful" that fancy session management is (Tmux as well as pulling an ecryptfs-mounted home folder out under my "feet"), I beg to differ regarding your "assessment".

[invot]

@0xC0000022L YMMV but I still disagree. AFAICS SystemD dramatically changes many traditional Unix aspects (for a reason) and this is why it must be such a monster. Session management is one of the key points here, as postmodern Desktops do not cope well with traditional Unix. If you disable one of SystemD's main strengths, you probably rather chose another init. For example Devuan works very well without SystemD. On a corporate level, with SystemD set and user profiles managed by LDAP, you do not want to edit logind.conf, instead loginctl enable-linger works (BTW I hate PAM, too).

[0xC0000022L]

Choice of the init system is no longer up to me as a user, unless I limit myself to what has become a rather narrow range of distros. And killing unrelated processes or dismounting the share of a currently active logged on user in response to "closing a login session" from a daemon is just not acceptable. No discussion needed. Please, enlighten me, though ... what is the conceptual difference between manually enable session lingering for the current user and persisting that in logind.conf for the same current user? I don't see one, but since you seem so passionate ... inform me.

[invot]

@0xC0000022L As you wrote. /etc/systemd/logind.conf is a global per-machine setting, while loginctl enable-linger is per-user. Hence editing /etc/systemd/logind.conf only works for some very special cases (like standalone single-user workstations) which can be statically handled while loginctl enable-linger/disable-linger works in all situations (like for LDAP based accounts etc.). Tweaking configuration files also puts more burden on upgrades, i.E. apt-get upgrade starts to ask if you want to install the maintainer version, and if you decline you might miss some new feature.

[invot]

@bobcat Good catch! This is a permanent setting. According to man loginctl changing this setting requires a reboot to become effective (doc states that the manager is started at boot time only)! Changed my answer accordingly. Thanks!