| Summary: | ksmserver doesn't announce itself as session leader using TakeControl() | ||
|---|---|---|---|
| Product: | [Unmaintained] ksmserver | Reporter: | Elias Probst <mail> |
| Component: | general | Assignee: | Lubos Lunak <l.lunak> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | CC: | afiestas, aleixpol, josef64, proninyaroslav |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| URL: | https://git.reviewboard.kde.org/r/118804/ | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Elias Probst
2014-05-26 21:10:44 UTC
@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. *** |