Bug#946645: KillUserProcesses=no disregarded for some cgroups

[chrysn]

Package: systemd
Version: 244-3
Severity: normal
File: /usr/share/man/man5/logind.conf.5.gz

The documentation about KillUserProcesses claims that processes will be
left alive after user logout when set to "no", and specifically mentions
tmux as one application.

This is only correct under some circumstances (apparently related to
cgroups, but I'm not familiar enough with them to give good details).
The observed issue is as follows:

* In a fresh sid installation, start Gnome under X11 (Wayland not
  tested).
* Alt+F2, xterm
* tmux
* Ensure you recognize the screen again later on
* Log out
* Log in back again, open xterm again
* tmux attach: "no sessions" -- the session was killed

In comparison, when `gnome-terminal` is used to start the tmux session,
it does survive the logout.

In drilling down to finding the difference at all (a process that seemed
very random to me in #945540, when I failed to take the terminal program
used into consideration), I noticed that the cgroups involved depended
on the terminal used: With xterm (or xfce4-terminal), the process seems
to be launched with cgroups pids, memory, name and "" in
/user.slice/user-$UID.slice/session-$SESSION.scope, whereas a surviving
tmux has its "", name and memory cgroups set to
/user.slice/user-$UID.slice/user@$UID.service/gnome-terminal-server.service
and the pids to /user.slice/user-$UID.slice/user@$UID.service.

It seems to me that processes under session-$SESSION.scope do get reaped
(whether deliberately killed by logind or somehow implicily by their
cgroups going away) at logout, and only those staretd from a program
that happens to switch cgroups survive.

Please change logind behavior to allow for all processes spawned in a
login session to survive, or if that is not possible, describe in the
KillUserProcesses which processes have a chance to survive.


For now, a usable workaround for me is to `systemd-run --user --scope
tmux` instead of tmux, but that's a workaround nobody should need to
use, especially as finding the need to do so usually involves having
lost one's tmux sessions over an X server crash before.

Thanks
chrysn


(Information down here relates to my production system where I've
reproduced the steps above with i3 instead of gnome).

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser          3.118
ii  libacl1          2.2.53-5
ii  libapparmor1     2.13.3-7
ii  libaudit1        1:2.8.5-2+b1
ii  libblkid1        2.34-0.1
ii  libc6            2.29-6
ii  libcap2          1:2.27-1
ii  libcryptsetup12  2:2.2.2-1
ii  libgcrypt20      1.8.5-3
ii  libgnutls30      3.6.10-5
ii  libgpg-error0    1.36-7
ii  libidn2-0        2.2.0-2
ii  libip4tc2        1.8.4-1
ii  libkmod2         26-3
ii  liblz4-1         1.9.2-2
ii  liblzma5         5.2.4-1+b1
ii  libmount1        2.34-0.1
ii  libpam0g         1.3.1-5
ii  libpcre2-8-0     10.34-7
ii  libseccomp2      2.4.2-2
ii  libselinux1      2.9-3+b1
ii  libsystemd0      244-3
ii  mount            2.34-0.1
ii  util-linux       2.34-0.1

Versions of packages systemd recommends:
ii  dbus  1.12.16-2

Versions of packages systemd suggests:
ii  policykit-1        0.105-26
pn  systemd-container  <none>

Versions of packages systemd is related to:
pn  dracut           <none>
ii  initramfs-tools  0.135
ii  udev             244-3

-- no debconf information