authentication required for suspending while others are logged in

[rjvbb]

An additional observation: logging off and back in resets something that cancels the issue. It's not really a solution, and s*cks as a workaround, but it does show that systemd-loging apparently *is* capable of updating the relevant state info without being restarted itself.

Does anyone have suggestions what things to attempt with the available ways of controlling this daemon so I can add as much relevant info as possible to the bug report?

I hope it's just a matter of "backporting" an ustream update to 14.04 as a sign of the supposedly long-term love (just like they could update apt to avoid gpg's limit on the number of PPA keys)

[SteveRiley]

I would have done that if I thought this had to do with KDE. I think it's more an issue with (K)Ubuntu's version of systemd-logind.

That's a good point. In 14.04, *buntu began deprecating ConsoleKit because it's been unmaintained for quite some time now. The replacement was logind from systemd (14.04 still uses Upstart as its init system).

Perhaps filing a bug against systemd-services makes more sense here.

[rjvbb]

I would have done that if I thought this had to do with KDE. I think it's more an issue with (K)Ubuntu's version of systemd-logind.

What part of KDE would you think has the bug, and that has been updated recently on Kubuntu 14.04 LTS?

[SteveRiley]

This sounds like a KDE bug, not a Kubuntu bug. Could we encourage you to file a bug at https://bugs.kde.org?

[rjvbb]

Does this behavior present if you do not open/log in to a virtual terminal before suspending?

Ah, forgot to clarify that.

No, it does not. But once I have logged into and out of a virtual terminal, I get the undesired behaviour.

In fact, I would also consider it undesirable if I were still logged in to a virtual terminal. I don't become another user if I log in there.

I haven't checked logging in as another user over ssh, but logging in that way myself does not impede suspension at all.

[Snowhog]

Does this behavior present if you do not open/log in to a virtual terminal before suspending?

[rjvbb]

Hello,

Since a couple of weeks I've been noticing issues putting my laptop to sleep that weren't there before.

- the process can take considerably longer if I suspend by closing the lid (hardware-initiated)
- the process never concludes when I use a software initiated message ("Suspend to RAM" from a "Leave" dialog), which is the method I usually prefer *); it simply locks the screen.

The reason for this becomes clear *after* waking the system from sleep, or after deactivating the screenlock:

"Authentication is required for suspending the system while other users are logged in"
After expansion, the Details section shows:
Action: "Suspend the system while other users are logged in"
Vendor: "The systemd Project" [Ah, right ... ]
polkit.subject-pid: points to kded4
polkit.called-pid: points to systemd-logind
The Action text is clickable and should allow me to edit org.freedesktop.login1.suspend-multiple-sessions but that doesn't work.

Here, "other users" means that I myself have logged in to a virtual terminal. It doesn't matter whether I still a: even after logging out from that session that pesky dialog still interferes with my main session.

Needless to say that it is of no use to unlock the screen and then enter my pw into that dialog: the suspension procedure will have been interrupted by then.

From what I can see, it's something from polkit that is responsible for this new behaviour.
Can it be unconfigured again one way or another? I'm an admin user, I should be able to suspend the system without having to authentify.

*) software in control of the hardware, not the other way round: this method gives me a smoother wake-from-sleep whereas with the other method I often see my session before the screen lock kicks in as configured.