Version-Release number of selected component (if applicable): kde-workspace-4.10.1-2.fc18.x86_64 polkit-kde-0.99.0-5.fc18.x86_64 polkit-qt-0.103.0-7.fc18.x86_64 polkit-0.107-4.fc18.x86_64 qt-4.8.4-14.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. Log in as user1 (member of wheel, don't know if it is important) 2. Switch to a new session, log in as user2 (not a member of wheel) 3. Switch back to the first session 4. Try to suspend the computer Actual results: Polkit-kde asks for credentials but all keyboard and mouse input is being refused. After 25 seconds the (user1's) lockscreen appears, allowing the input again. After unlocking the desktop, one can input his password again into the polkit-kde prompt which is still there. Entering the correct password won't do anything, however. The desktop is suspended once the user has attempted to suspend the desktop once again (this time he doesn't have to input the password though). Expected results: Polkit-kde asks for credentials, allows input, suspends the computer if the credentials were right. Additional info: Both sessions mentioned were KDE Plasma Workspaces in a clean updated Fedora 18 installation. I think this started to happen in 4.10 with the new screensaver but I'm not sure.
*** Bug 951176 has been marked as a duplicate of this bug. ***
The same error happens when KDM is used, too. Also the delay is there only because the screenlocker takes long time to load and the second attempt is not needed if the desktop is unlocked faster. Bug seems to be in PowerDevil, the locking code is called before the suspending (hibernating) code and doesn't expect the suspend would need any kind of user interaction.
Odd that this happens in the first place. Unless this is a known problem? Can you do 'loginctl list-sessions' to see your session id and 'loginctl session-status <ID> | grep State' to see whether it's active? Doing this before, during (from the other session or with 'sleep') and after switching should tell us if anything funny's going on,
It's like this all the time: Session 4: State: online Session 5: State: active # the session that triggered the suspension I think this is alright. Using false as a parameter to Suspend(bool interactive) call on the login1 interface suspends the computer without asking for password. Honestly, I can't tell if this is a workaround or a proper fix since there's the issue with password entry on closing the lid. But that would mean having a defective policy anyway... Still (as I wrote on the list), I think there should be the proposed signal to start the screensaver properly and fully. Link to the discussion: http://mail.kde.org/pipermail/kde-hardware-devel/2013-April/002151.html
OK, I understand this a bit better now. The relevant policies are org.freedesktop.login1.suspend-multiple-sessions (allows active user to suspend) and org.freedesktop.login1.hibernate-multiple-sessions (requires authentication) I guess that you're hibernating and not suspending to trigger this? I'm not sure what the use is of having different policy for suspend and hibernate is? Perhaps the org.freedesktop.login1.hibernate-multiple-sessions policy should be relaxed to match the suspend one? I see the suspend policy has already been loosened to its current state in systemd commit 9d17cf3e93414ad604669ef908e86ccec9056a0 (In reply to comment #4) > Using false as a parameter to Suspend(bool interactive) call on the login1 > interface suspends the computer without asking for password. Probably because the "hibernate with multiple sessions" policy is auth_admin_keep so the second attempt succeeds. This also explains your similar observation in comment #0. > Honestly, I can't tell if this is a workaround or a proper fix since there's > the issue with password entry on closing the lid. But that would mean having > a defective policy anyway... I think in normal situations if you pass false as the interactive boolean and the policy is auth_admin then it will simply fail. Maybe it should also fail for auth_admin_keep even if you have already entered a password? That's a question for the polkit people to answer though.
(In reply to comment #5) > OK, I understand this a bit better now. The relevant policies are > org.freedesktop.login1.suspend-multiple-sessions (allows active user to > suspend) and org.freedesktop.login1.hibernate-multiple-sessions (requires > authentication) > > I guess that you're hibernating and not suspending to trigger this? You're right, sorry, I'm always mistaking these two. > I'm not sure what the use is of having different policy for suspend and > hibernate is? Perhaps the org.freedesktop.login1.hibernate-multiple-sessions > policy should be relaxed to match the suspend one? I see the suspend policy > has already been loosened to its current state in systemd commit > 9d17cf3e93414ad604669ef908e86ccec9056a0 Yes but I'm still concerned about the design issue in PowerDevil often causing the screensaver to be fully loaded after waking up. > Probably because the "hibernate with multiple sessions" policy is > auth_admin_keep so the second attempt succeeds. This also explains your > similar observation in comment #0. > I think in normal situations if you pass false as the interactive boolean > and the policy is auth_admin then it will simply fail. Maybe it should also > fail for auth_admin_keep even if you have already entered a password? That's > a question for the polkit people to answer though. Yes, you're right, it indeed doesn't do anything for the first time. There isn't even a reply to the call.
i dont have gdm installed at all but i have this problem. my system uses kde exclusively. i reported my issue in bug 995718 but i am still unclear whether this is the same, related or unrelated. my system is fedora 19 x86 and i see it a lot on the family laptop
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.