$ systemd-inhibit --list WHAT WHO WHY MODE UID PID handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch PowerDevil KDE handles p...ents block 1000 2535 sleep root inhibited delay 0 674 The second inhibit is requested by networkmanager. Now when I suspend the computer (by KDE), it will do another suspend just after wakeup. When down grade to nm without this inhibit, problem would disappear. Not sure systemd/nm/KDE which should I report bug to, but I just leave it here for advice.
I guess KDE hasn't really been updated to deal with logind properly. Also see: https://bugzilla.redhat.com/show_bug.cgi?id=859227
Are you mean UPower.Suspend should not be used and should only use org.freedesktop.login1.Manager.Suspend?
And if so, should it be updated on upower side to support systemd suspend, or should it be updated on kde side to use systemd suspend?
I already take the patch from https://git.reviewboard.kde.org/r/108407/ And debug message shows it works, but double suspend still happen when close the lid. BTW, since this is still related if networkmanager inhibit lock existence, I wonder there still be a bug in how systemd handle the sleep inhibit? It just happens randomly so I guess there is some race condition exist. But since suspend to login1 is only fired once, the problem doesn't belongs to kde side. Is it related that while system suspends I see a kernel message tty?
I think th
I still think there is a bug in how systemd handling both suspend request from dbu, lid close, and delay inhibit lock. Apparently, I already applied the patch for kde power management, I think there is not much can be done from KDE side. The bug CANNOT be reproduced if: 1. suspend from a gui from kde 2. no other delay inhibit lock Currently the only case that can reproduce it is: suspend via close lid So somehow I think systemd queued the close lid event, and at some point "reprocess" the event which should be blocked by kde.
Seeing this same "double suspend" problem here with KDE/systemd. This faulty behaviour only occurs when attempting to resume after lid-close.
To be clear, the support added to kde upstream (definitely in 4.10.2, maybe earlier...) is that systemd's logind support is used with systemd >= 198 (1), and falls back to upower otherwise. In my experience, this bug only happened in the upower fallback case, and I suspect some race/bug there. (1) fedora 18's systemd-197 packages have additional patches that allow use there too.
I am pretty sure this is somewhere between KDE and upower, systemd is not doing double suspends. Closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.