<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 13, 2020 at 8:15 PM Bernie Innocenti <<a href="mailto:bernie@codewiz.org" target="_blank">bernie@codewiz.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 13/07/2020 17.48, David Edmundson wrote:<br>
> <br>
> <br>
> On Sun, Jul 12, 2020 at 5:29 PM Bernie Innocenti <<a href="mailto:bernie@codewiz.org" target="_blank">bernie@codewiz.org</a> <br>
> <mailto:<a href="mailto:bernie@codewiz.org" target="_blank">bernie@codewiz.org</a>>> wrote:<br>
> <br>
>     (re-posting because most subscribers might have missed my previous post<br>
>     due to an excessively strict DKIM policy applied by my domain).<br>
> <br>
> <br>
>     I'm trying to fix this longstanding bug where there are dangling user<br>
>     processes after the desktop session exists:<br>
> <br>
>     <a href="https://bugs.kde.org/show_bug.cgi?id=359651" rel="noreferrer" target="_blank">https://bugs.kde.org/show_bug.cgi?id=359651</a><br>
>     <<a href="https://bugs.kde.org/show_bug.cgi?id=359651" rel="noreferrer" target="_blank">https://bugs.kde.org/show_bug.cgi?id=359651</a>><br>
> <br>
>     This is reproducible every time on multiple distributions and KDE<br>
>     versions. It also causes subsequent logins to fail or behave<br>
>     surprisingly due to the presence of extraneous dbus services,<br>
>     pulseaudio<br>
>     clients, etc.<br>
> <br>
> Yes it's a problem.<br>
> Pulseaudio deliberately tries to survive whilst a user is logged in, so <br>
> that's fine<br>
> The DBus services is a bit weird.<br>
> <br>
> Apparently gnome used to solve this problem by killing dbus-daemon <br>
> explicitly :/<br>
> <br>
>     I looked into plasma-workspace/startkde, and there's no hint of it<br>
>     starting "systemd --user" directly.<br>
> <br>
> <br>
>  >So I'm starting to think that it might be done implicitly via PAM<br>
> <br>
>     (there's a pam_systemd module).<br>
> <br>
> That's exactly what happens.<br>
> <br>
>     But, if a PAM module is starting "systemd<br>
>     --user", shouldn't the same PAM module also do the cleanup?<br>
> <br>
> <br>
> IMHO yes, what I've been trying to do to solve this is to make the <br>
> systemd user session aware of all our stuff.<br>
> We've currently introduced cgroups round the apps, we're tackling the <br>
> services slowly as part of the plasma boot.<br>
> <br>
> Then "all" we need to do is ship two drop-ins for app-*  and plasma-* <br>
> scopes and services.<br>
> That include the line BindsTo=graphic-session.target<br>
> <br>
> Once that ends, it'll tear down everything in a controlled manner just <br>
> like a system process.<br>
> This is also what gnome is doing to do.<br>
<br>
Do you have a work-in-progress patch I could see?<br>
<br></blockquote><div>The actual scoping of applications is already merged (see systemd-cgls on Plasma 5.19).</div></div><div class="gmail_quote">Scoping of the background services is on review and scattered around the place.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Then we need these drop-ins to scope them to the lifespan of the session.</div><div class="gmail_quote"><a href="https://invent.kde.org/davidedmundson/systemd-dropins">https://invent.kde.org/davidedmundson/systemd-dropins</a></div><div class="gmail_quote"><div></div><div> </div><div>Let me know if that makes a difference, it seems to be working nicely for me.</div><div><br></div><div>David<br></div><br></div></div>