As I have described on https://bugs.debian.org/761652 , I'm routinely running two KDE sessions in parallel, switching from the "personal" to the "professional" one regularily. The two PowerDevils that appear in systemd-inhibit --list make me think that the two of them act even when they're not the ones in charge for the currently active session. Reproducible: Always Steps to Reproduce: 1. Open two parallel KDE sessions 2. Configure the two PowerDevils to suspend-on-lid-close 3. Close the lid in hope that the laptop will always suspend. Actual Results: Notice that the laptop doesn't suspend and that an authorization window is displayed on the 'inactive' session (behind the locking screen, of course). Expected Results: The "inactive" PowerDevil should have done strictly nothing and left the "active" PowerDevil handle the actions. I've also reported the same bug against systemd https://bugs.freedesktop.org/show_bug.cgi?id=85518 but the more thought I've put to this problem the more I suspect PowerDevil's to be at fault here.
*** Bug 328336 has been marked as a duplicate of this bug. ***
This would also solve problems with suspend button not working on lock screen. When locked, Powerdevil should release inhibit on buttons too and let systemd-logind (or acpid or other system service) handle the situation.
I wonder if the specific described issue is still a problem. Without two sessions, both the "Sleep" button and closing the lid works for me without having to authenticate. Bug 390634 (and related bugs mentioned there) suggest that related behavior was changed since this issue got reported. However I'd piggyback on this issue because even if the specific described situation is not a problem anymore, the fundamental issue still exists, and Bug 328336 getting merged here suggests that we should consider the issue in the title, not just the specific situation in the first comment. In my case playing a video and locking the screen still leaves the video playback's power management inhibition active, so even though the video can't be seen, the screen never turns off which is a power waste now, but more and more likely to be a source of OLED burn-in as OLED monitors are getting cheaper (a significant change in the monitor market is expected next year). The issue isn't straight-forward though as a session which still exists can be quite active from some perspectives, so I can see shutdown/sleep/hibernation inhibition making sense in cases like long running programs (video rendering, AI/ML training) not wanting to be interrupted despite not having user interactivity, but the mentioned screen power management inhibition in the case of not even having anything visible from a session surely doesn't make sense.