Bug#992990: systemd: Does not clean up user session

[Michael Biebl]

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