In case systemd-logind is available, ksmserver should register itself as session leader. Otherwise a lot of things will be broken such as: - unlocking the screen is impossible - talking to system DBus services which have an `at_console` policy is impossible - trying to shut down a KDE session does nothing More details here: http://www.freedesktop.org/wiki/Software/systemd/logind/ Running KF5/Plasma fresh from git here, Qt 5.3.0 and systemd 212+ from git master. This all might be partially caused by the fact, that I'm running KF5/Plasma as a systemd user-session (early attempts to get KF5/Plasma ready for systemd user-sessions: https://github.com/eliasp/plasma-workspace-units/), but the missing TakeControl()/ReleaseControl() in ksmserver is IMHO a critical piece to getting further here. I don't know how the situation looks like in legacy sessions, but for me I always have 'sddm' (login manager) as the leading PID for the session (loginctl show-session $session-ID) by default as that's the process initiating the whole session via PAM.
@afiestas: Allowing myself to CC you here as mgraesslin told me you're the one with logind knowledge here.
Unless ksmserver doesn't TakeControl() of the current logind session, it'll log this message: The session is not registered with logind "PID 2979 does not belong to any known session" Looking at it, it makes me wonder whether ksmserver's logind integration ever worked at all as the only scenario where ksmserver's PID would be registered as session leader would require ksmserver to be the process launching the logind session, which is right now in almost any case the login manager (KDM, LightDM, sddm, ...).
Then, why do I get to shutdown?
(In reply to comment #3) > Then, why do I get to shutdown? Does the "Leader" PID in "loginctl show-session $XDG_SESSION_ID" match the PID of your ksmserver? If so, it would be interesting to find out, why… to my knowledge, it shouldn't, as the Leader PID defaults to the process initiating the session (KDM, LightDM, sddm, …) and needs to be re-assigned using TakeControl().
I see, I confirm that I have LightDM as Leader. Still, I get to shutdown my computer from kickoff. Anyway, it's definitely something to get sorted out. I'm quite clueless about the subject but I'll be happy to assist with testing and feedback.
A first attempt to fix this is available in RR#118804 [1], but unfortunately I didn't succeed for reasons still unknown to me. [1] https://git.reviewboard.kde.org/r/118804/
The patch in RR#118804 should basically work now, but there's some work to be done outside ksmserver. See also: http://lists.freedesktop.org/archives/systemd-devel/2014-June/020238.html http://lists.freedesktop.org/archives/systemd-devel/2013-February/009119.html
It looks, like ksmserver should never be the session leader. That's up to the display server and we (from a DE point of view) don't have to care about at all. So there's no need to register using TakeControl(). The reason I'm seeing the > The session is not registered with logind: "PID 2979 does not belong to any known session" message can be mostly attributed to the ongoing work of integrating systemd's user-session services properly with logind, as right now user-session services are started outside any logind session, causing logind to respond on 'GetSessionByPID' with the message above. Closing this bug and the RR. Sorry for the noise, but at least I feel now quite a bit more educated about how systemd-logind/D-Bus/user-session services etc. interact with each other.
*** Bug 355634 has been marked as a duplicate of this bug. ***