I'm on Gentoo, using xfce4-power-manager 1.4.2, systemd, upower, lightdm and light-locker. When I lock my session, I get switched to lightdm greeter, so my session becomes inactive. Now lid closed event should be handled by systemd-logind (and it's working fine), but xfce4-power-manager still receives upower notifications on lid closing and also tries to suspend. Put xfce4-power-manager fails to suspend when user session is inactive (polkit doesn't allow this), so error message window from polkit agent appears. xfce4-power-manager must not try to suspend on lid and button events when user session is not active. If you need more information, ask me, and I'll provide you what you need.
(In reply to Maxim Mikityanskiy from comment #0) > Put > xfce4-power-manager fails to suspend when user session is inactive (polkit > doesn't allow this), so error message window from polkit agent appears. Quick fix: But xfce4-power-manager fails to suspend when user session is inactive (polkit doesn't allow this without root authorization), so polkit agent window asking me root password appears.
If I understand you correctly, you're trying to suspend when you're at the greeter/lockscreen. Are you sure that xfce4-power-manager is running there? Could it be a polkit window triggered by the greeter/lightdm? Which greeter are you using?
(In reply to Simon Steinbeiss from comment #2) > If I understand you correctly, you're trying to suspend when you're at the > greeter/lockscreen. Are you sure that xfce4-power-manager is running there? I'm just closing lid when I'm at the greeter. Xfpm is running in my user's session. Xfpm isn't running in greeter's session. Xfpm from user's session catches lid event and tries to suspend, but my user's session is inactive, so root authentication window appears. Xfpm should not try to do any action when session is inactive. > Could it be a polkit window triggered by the greeter/lightdm? Which greeter > are you using? I'm using lightdm-gtk-greeter, but polkit window is definitely triggered by xfpm - it appears in my user's session, and then after some time notification from power manager appears with text: "GDBus.Error:org.freedesktop.DBus.Error.NoReply: Method call timed out".
That is a very strange bug, but I can actually reproduce it now (despite the fact that my laptop doesn't suspend at the greeter, but seemingly the lid event gets passed on to the inactive seat). Tbh I'm a bit stomped and am not sure what's going on there. I would presume that with the seat being inactive, these sort of events won't get passed down to it... Maybe we should ask the LightDM folks how this is supposed to work.
(In reply to Simon Steinbeiss from comment #4) > That is a very strange bug, but I can actually reproduce it now (despite the > fact that my laptop doesn't suspend at the greeter, but seemingly the lid > event gets passed on to the inactive seat). > > Tbh I'm a bit stomped and am not sure what's going on there. I would presume > that with the seat being inactive, these sort of events won't get passed > down to it... Maybe we should ask the LightDM folks how this is supposed to > work. LightDM is completely irrelevant here. I suppose you can reproduce the bug even if you just switch to another VT - session becomes inactive, but UPower events are still passed to xfpm, then xfpm tries to suspend, but polkit requires root authorization, because the session is inactive. I suggest to check if session is active, and only perform an action when it's active. It may also be useful to look how other power managers (gnome-power-manager and powerdevil) handle this situation. I could try to test what's going on with powerdevil a few days later.
I looked at powerdevil, and it suffers from the same problem. However, on my laptop there is a race condition between powerdevil and logind: if I close lid when KDE session is inactive, logind starts suspending the system, then powerdevil tries to suspend, but receives a error: "There's already a shutdown or sleep operation in progress". It doesn't show this message in a window, it doesn't even get to log because of another bug in powerdevil. But I was able to reproduce xfce4-power-manager's bug with powerdevil: if I set HandleLidSwitch=ignore in logind.conf, powerdevil tries to suspend, but the session is inactive, so password prompt appears, just as with xfce4-power-manager. So... both xfce4-power-manager and powerdevil should check if the session is active, before suspending. But powerdevil code may be useful, as there is really some part that checks if the session is active. You can look at git://anongit.kde.org/kde-workspace for file kde-workspace/powerdevil/daemon/powerdevilpolicyagent.cpp. Especially look at functions PolicyAgent::onSessionHandlerRegistered and PolicyAgent::onActiveSessionChanged.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/8. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev