[systemd-devel] Should pam-activated systemd --user daemon quit after session has been closed?

[Kai Krakow]

Am Fri, 22 Jan 2016 23:19:11 +0100
schrieb "Armin K." <krejzi at email.com>:

> I have a following problem on my system and it has been bothering me
> for some time.
> 
> I use KDE Plasma 5 and lightdm as a display manager to login to the
> session. Once logged in, the lightdm (I guess it's using
> pam_systemd.so) login service will also start systemd user session
> and a session dbus daemon. The rest of Plasma follows.
> 
> The problem is, that whenever I log out from Plasma, the systemd user
> session isn't terminated and as such leaves the user bus daemon and
> lots of services around, which makes shutdown hang (if I initiated
> the shutdown, which will first initiate log out) for some time (90
> seconds by default until it's forcibly killed by systemd) which I
> rather find annoying. I can see the systemd user session is the
> culprit, because I can see "Waiting for session for user 1000 to
> terminate [timer]" or something like that.
> 
> When I just log out, I can manually stop the systemd user session
> using loginctl kill-user/kill-session (I am not sure which one I used
> last time), which will terminate user bus and all the other services
> from that session.
> 
> Now, to the original question: Once PAM closes the session (once
> logout is received), should systemd --user daemon terminate as well?
> Currently, that's not the case on my system.
> 
> Let me know if I can provide any additional info.

Have you tried SDDM instead of LightDM... SDDM is recommended for KDE
Plasma 5 afaik. I had similar issues with shutdown when I still used
LightDM. Tho I never tracked it back due to an orphan user session -
good catch.


-- 
Regards,
Kai

Replies to list-only preferred.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20160122/201a9767/attachment-0001.sig>