Bug#992990: systemd: Does not clean up user session
Hello, Michael Biebl, le sam. 25 sept. 2021 17:36:05 +0200, a ecrit: > On Thu, 26 Aug 2021 17:21:39 +0200 Samuel Thibault > wrote: > > Control: tags -1 wontfix > > > > So AIUI, to get a proper cleanup when the X server happens to go away > > (lightdm restart, or main session process exit), the processes have to > > notice that the X server went away? > > Not sure what to do about this bug report. > Do you want to keep it open asking for `KillUserProcesses=yes` to be the new > default? I understand that the "screen" case makes it quite unlikely that KillUserProcesses=yes becomes a default. So perhaps we can just close it. Samuel
Bug#992990: systemd: Does not clean up user session
On Thu, 26 Aug 2021 17:21:39 +0200 Samuel Thibault wrote: > Control: tags -1 wontfix > > So AIUI, to get a proper cleanup when the X server happens to go away > (lightdm restart, or main session process exit), the processes have to > notice that the X server went away? Not sure what to do about this bug report. Do you want to keep it open asking for `KillUserProcesses=yes` to be the new default? If not, is there a benefit to keep it open? Michael signature.asc Description: This is a digitally signed message part
Bug#992990: systemd: Does not clean up user session
Control: tags -1 wontfix So AIUI, to get a proper cleanup when the X server happens to go away (lightdm restart, or main session process exit), the processes have to notice that the X server went away? Samuel
Bug#992990: systemd: Does not clean up user session
Am 26.08.21 um 15:58 schrieb Ansgar: On Thu, 2021-08-26 at 09:13 +0200, Michael Biebl wrote: In your case, dbus-daemon is *not* started as a user service, but as a regular process within a login session, so there can be multiple ones. This looks incorrect: dbus was started with `--address=systemd` and `--systemd-activation`. So it looks like it was started via systemd as a user service. Right, sorry. I was confused by the instance that was started via AT-SPI. systemd does have a facility `KillUserProcesses=yes` which kills all processes of such a login session, when the user logs out. The upstream default is "yes" but in Debian we had complaints that this killed processes like screen, so we patch it to "no" as default in Debian. And with `KillUserProcesses=no` any process still left in the user's login session will keep the login alive (in "closing" state) and the user's `systemd --user` instance and thus dbus will be kept running. Nod, the end result is the same and the underlying issue is that we default to `KillUserProcesses=no` OpenPGP_signature Description: OpenPGP digital signature
Bug#992990: systemd: Does not clean up user session
On Thu, 2021-08-26 at 09:13 +0200, Michael Biebl wrote: > In your case, dbus-daemon is *not* started as a user service, but as > a > regular process within a login session, so there can be multiple > ones. This looks incorrect: dbus was started with `--address=systemd` and `--systemd-activation`. So it looks like it was started via systemd as a user service. > systemd does have a facility `KillUserProcesses=yes` which kills all > processes of such a login session, when the user logs out. > The upstream default is "yes" but in Debian we had complaints that > this > killed processes like screen, so we patch it to "no" as default in > Debian. And with `KillUserProcesses=no` any process still left in the user's login session will keep the login alive (in "closing" state) and the user's `systemd --user` instance and thus dbus will be kept running. Ansgar
Bug#992990: systemd: Does not clean up user session
Michael Biebl, le jeu. 26 août 2021 09:13:02 +0200, a ecrit: > There is no way you can differentiate whether a process is "good" and should > survive a logout or a lingering process is bad and should be killed. > > The only way this could work is if processes would actually tell systemd > this, e.g. screen could have used "systemd-run" to create an ephemeral scope > unit. This suggestion was rejected by the screen maintainers/upstream afair. > > So, with the current setup we can't please everyone. Ok :/ So we'll have to live with that. Samuel
Bug#992990: systemd: Does not clean up user session
From README.Debian: KillUserProcesses behavior in Debian If KillUserProcesses=yes is configured in logind.conf(5), the session scope will be terminated when the user logs out of that session. See logind.conf(5): | Note that setting KillUserProcesses=yes will break tools like screen(1) and | tmux(1), unless they are moved out of the session scope. The default for KillUserProcesses in /etc/systemd/logind.conf is set to "yes" in upstream systemd, though Debian defaults to "no" (see #825394). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 OpenPGP_signature Description: OpenPGP digital signature
Bug#992990: systemd: Does not clean up user session
Am 26.08.21 um 01:26 schrieb Samuel Thibault: Package: systemd Version: 247.3-6 Severity: normal Hello, It seems that the user sessions are not getting cleaned up when it crashes unexpectedly, and notably the dbus session bus, which can lead to various oddities. To reproduce: - logging in from lightdm ($USER is ff) - the MATE desktop starts - the attached snapshot shows the dbus-daemon running: not only the ones for the ff user, but also for lightdm (!?) - as root in a mate-terminal, run systemctl restart lightdm - the MATE session thus gets completely interrupted, lightdm shows up again - logging in again as $USER ff - the MATE desktop starts - the attached snapshot shows that it's still the same dbus-daemon running: again not only the ones for the ff user, but also for lightdm These surviging processes are worrying: when a user is not connected, should there really be such remainings? I understand that a user may be running e.g. screen sessions, but more than this? I could check that systemd 249.3-3 from experimental behaves the same First of all, I think what you mean here are login/logind sessions. user sessions are defined by the lifetime of the systemd --user instance and there can only be one instance of systemd --user per user. user services are started by systemd --user and are shared between login sessions. In your case, dbus-daemon is *not* started as a user service, but as a regular process within a login session, so there can be multiple ones. systemd does have a facility `KillUserProcesses=yes` which kills all processes of such a login session, when the user logs out. The upstream default is "yes" but in Debian we had complaints that this killed processes like screen, so we patch it to "no" as default in Debian. So, we can't have it both ways unfortunately. There is no way you can differentiate whether a process is "good" and should survive a logout or a lingering process is bad and should be killed. The only way this could work is if processes would actually tell systemd this, e.g. screen could have used "systemd-run" to create an ephemeral scope unit. This suggestion was rejected by the screen maintainers/upstream afair. So, with the current setup we can't please everyone. Michael
Bug#992990: systemd: Does not clean up user session
Package: systemd Version: 247.3-6 Severity: normal Hello, It seems that the user sessions are not getting cleaned up when it crashes unexpectedly, and notably the dbus session bus, which can lead to various oddities. To reproduce: - logging in from lightdm ($USER is ff) - the MATE desktop starts - the attached snapshot shows the dbus-daemon running: not only the ones for the ff user, but also for lightdm (!?) - as root in a mate-terminal, run systemctl restart lightdm - the MATE session thus gets completely interrupted, lightdm shows up again - logging in again as $USER ff - the MATE desktop starts - the attached snapshot shows that it's still the same dbus-daemon running: again not only the ones for the ff user, but also for lightdm These surviging processes are worrying: when a user is not connected, should there really be such remainings? I understand that a user may be running e.g. screen sessions, but more than this? I could check that systemd 249.3-3 from experimental behaves the same Samuel -- Package-specific info: -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.0 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii adduser3.118 ii libacl12.2.53-10 ii libapparmor1 2.13.6-10 ii libaudit1 1:3.0.5-1 ii libblkid1 2.36.1-8 ii libc6 2.31-13 ii libcap21:2.44-1 ii libcrypt1 1:4.4.18-4 ii libcryptsetup122:2.3.5-1 ii libgcrypt201.8.7-6 ii libgnutls303.7.1-5 ii libgpg-error0 1.38-2 ii libip4tc2 1.8.7-1 ii libkmod2 28-1 ii liblz4-1 1.9.3-2 ii liblzma5 5.2.5-2 ii libmount1 2.36.1-8 ii libpam0g 1.4.0-9 ii libseccomp22.5.1-1 ii libselinux13.1-3 ii libsystemd0247.9-1 ii libzstd1 1.4.8+dfsg-2.1 ii mount 2.36.1-8 ii ntp [time-daemon] 1:4.2.8p15+dfsg-1 ii util-linux 2.36.1-8 Versions of packages systemd recommends: ii dbus 1.13.18-1 Versions of packages systemd suggests: ii policykit-10.105-31 pn systemd-container Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.140 ii libnss-systemd 247.9-1 ii libpam-systemd 247.9-1 ii udev 247.9-1 -- Configuration Files: /etc/systemd/journald.conf changed [not included] /etc/systemd/logind.conf changed [not included] -- no debconf information -- Samuel #include
