Re: Killing the systemd user session on logout

[Bernie Innocenti]

+sddm-...@googlegroups.com

On 12/07/2020 02.27, Bernie Innocenti wrote:
> On 12/07/2020 00.14, Bernie Innocenti wrote:
>> 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.
>>
>> I looked into plasma-workspace/startkde, and there's no hint of it
>> starting "systemd --user" directly. There's this cli tool called
>> "kde-systemd-start-condition" (which appears to be unused), and a few
>> other mentions of logind and systemd, but nothing really relevant.
>>
>> Am I looking in the wrong place?
>
> Hmm, well, maybe sddm was the right place to look. I see various places
> where sddm talks about the session with the login1 dbus service:
>
>   https://github.com/sddm/sddm/blob/develop/src/daemon/Display.cpp
>
>
> Yet, I can't spot the exact place where the session is created. I guess
> the fix for this bug might involve sending a KillSession message after
> startplasma-x11 or startplasma-wayland has exited. Maybe from
> HelperApp::sessionFinished?
>


--
_ // Bernie Innocenti
\X/ https://codewiz.org/

[Bernie Innocenti]

(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.

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

Then I thought that perhaps SDDM starts the systemd session, but
couldn't find the exact spot in the code. I see communication about the
session with login1, but not an explicit CreateSession:

https://github.com/sddm/sddm/blob/develop/src/daemon/Display.cpp

So I'm starting to think that it might be done implicitly via PAM
(there's a pam_systemd module).

I guess the fix for this bug might involve sending a KillSession message
after startplasma-x11 or startplasma-wayland has exited. Maybe from

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

[David Edmundson]

On Sun, Jul 12, 2020 at 5:29 PM Bernie Innocenti <ber...@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]

Do you have a work-in-progress patch I could see?


By the way, I've been looking into this other bug where starting a
Plasma session will eat a VT even after logging out:

https://github.com/sddm/sddm/issues/1200#issuecomment-657084636

I believe we're leaking the fd. Could you confirm that I'm on the right
track? This is my first tentative fix:

https://codewiz.org/pub/sddm-fd-leak.patch

I wasn't able to test it because I couldn't figure out how to run my own
sddm build without overwriting the system binaries.

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

> <https://systemd.io/DESKTOP_ENVIRONMENTS/>

Interesting read.

> David
>
>
> --
> _ // Bernie Innocenti

> \X/ https://codewiz.org/ <https://codewiz.org/>

[David Edmundson]

The actual scoping of applications is already merged (see systemd-cgls on Plasma 5.19).

Scoping of the background services is on review and scattered around the place.

Then we need these drop-ins to scope them to the lifespan of the session.

https://invent.kde.org/davidedmundson/systemd-dropins

 

Let me know if that makes a difference, it seems to be working nicely for me.

David