4

So far I was used to be able to run tmux via SSH and if I disconnected, the tmux session would still be running when I connected back.

So I assumed that the same could be done by starting a tmux session as one user (using GNOME's Terminal application) and then log out of GNOME and reconnect to it, e.g. via SSH. Turns out I was wrong.

Interestingly when I do the following as a workaround, it seems to work:

  1. ssh $(whoami)@localhost
  2. start tmux session
  3. disconnect
  4. log off from GNOME
  5. log back in as another user
  6. use SSH to connect to the user from step 1
  7. reconnect to tmux session

Alas, I don't get why GNOME seemingly kills all the processes of said user when logging off.

Is there a better way than the above workaround? Some GNOMEish counterpart of Bash's built-ins fg/bg/disown, perhaps?

0xC0000022L
  • 16,593

2 Answers2

3

Meanwhile I have researched this further. The pointer with systemd by Nicholas was spot on. Several ways seem to exist to mitigate the issue:

1. logind.conf

/etc/systemd/logind.conf and friends contain three relevant settings:

  • KillUserProcesses= (if yes a logoff will cause processes within the scope of the systemd-logind.service(8) session to be killed.
  • KillOnlyUsers= will allow to limit the list of users for which the above setting applies (space-separated list, e.g. adam eve joe jane).
  • KillExcludeUsers= is the opposite of the previous setting an makes users exempt from the effect of KillUserProcesses=yes.

So one could set KillUserProcesses=no or only include user gdm in KillOnlyUsers (if using GNOME) or list the users to be exempt from process killing on login session teardown via KillExcludeUsers.

You can see sessions with loginctl list-sessions.

2. loginctl enable-linger username

You can enable lingering for the current session by executing loginctl(1) as follows within the session scope (obviously replace username for the actual user name or $(whoami)):

loginctl enable-linger username

The clue can be found from the logind.conf(5) manual page:

In addition to session processes, user process may run under the user manager unit user@.service. Depending on the linger settings, this may allow users to run processes independent of their login sessions. See the description of enable-linger in loginctl(1).

3. systemd-run --scope --user command

The manual for logind.conf(5) contains the clue to this one:

Note that setting KillUserProcesses=yes will break tools like screen(1) and tmux(1), unless they are moved out of the session scope. See example in systemd-run(1).

And indeed looking at the manual for systemd-run(1) we find the following example:

Example 5. Start screen as a user service

$ systemd-run --scope --user screen Running scope as unit
run-r14b0047ab6df45bfb45e7786cc839e76.scope.

$ screen -ls There is a screen on:
        492..laptop     (Detached) 1 Socket in /var/run/screen/S-fatima.

This starts the screen process as a child of the systemd --user process that was started by user@.service, in a scope unit. A systemd.scope(5) unit is used instead of a systemd.service(5) unit, because screen will exit when detaching from the terminal, and a service unit would be terminated. Running screen as a user unit has the advantage that it is not part of the session scope. If KillUserProcesses=yes is configured in logind.conf(5), the default, the session scope will be terminated when the user logs out of that session.

Tested with

systemd 245 (245.4-4ubuntu3.2)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid
0xC0000022L
  • 16,593
1

It could be this is related to systemd, at some point I heard that they were killing all daemon processes on logoff (ignoring decades of previous Unix practice!), but I haven't heard of it for a while so I thought they either changed back, that it is something that is easy to fix or that packagers were dealing with so users didn't see it.

Anyway, if it is systemd, there are other answers that you mind find and try, for example here.

0xC0000022L
  • 16,593
Nicholas Marriott
  • 3,860
  • Whoa ... thanks for the answer. But most of all thanks for Tmux! (and still taking the time to answer). – 0xC0000022L Apr 29 '20 at 09:09
  • 1
    It will be related to GNOME Terminal. See https://unix.stackexchange.com/a/407863/5132 . The server runs as a per-user service, and per-user service management is torn down at logoff. – JdeBP Apr 29 '20 at 10:33