Killing the systemd user session on logout

[David Edmundson]

On Sun, Jul 12, 2020 at 5:29 PM Bernie Innocenti <bernie at codewiz.org> wrote:

> (re-posting because most subscribers might have missed my previous post
> due to an excessively strict DKIM policy applied by my domain).
>
>
> I'm trying to fix this longstanding bug where there are dangling user
> processes after the desktop session exists:
>
>    https://bugs.kde.org/show_bug.cgi?id=359651
>
> This is reproducible every time on multiple distributions and KDE
> versions. It also causes subsequent logins to fail or behave
> surprisingly due to the presence of extraneous dbus services, pulseaudio
> clients, etc.
>
> Yes it's a problem.
Pulseaudio deliberately tries to survive whilst a user is logged in, so
that's fine
The DBus services is a bit weird.

Apparently gnome used to solve this problem by killing dbus-daemon
explicitly :/



> I looked into plasma-workspace/startkde, and there's no hint of it
> starting "systemd --user" directly.
>

>So I'm starting to think that it might be done implicitly via PAM

> (there's a pam_systemd module).
>
> That's exactly what happens.


>

> But, if a PAM module is starting "systemd
> --user", shouldn't the same PAM module also do the cleanup?
>

IMHO yes, what I've been trying to do to solve this is to make the systemd
user session aware of all our stuff.
We've currently introduced cgroups round the apps, we're tackling the
services slowly as part of the plasma boot.

Then "all" we need to do is ship two drop-ins for app-*  and plasma-*
scopes and services.
That include the line BindsTo=graphic-session.target

Once that ends, it'll tear down everything in a controlled manner just like
a system process.
This is also what gnome is doing to do.

Some notes about that topic: https://systemd.io/DESKTOP_ENVIRONMENTS/

David


> --
> _ // Bernie Innocenti
> \X/  https://codewiz.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20200713/fca13800/attachment.htm>