Description of problem: Selecting "Hibernate" in KDE results in a hibernated image which will restart to the user's desktop without asking a password. After selecting "hibernate" from the KDE menu as a normal user, the system asks for root permission to continue. However, this dialog is only shown for a fragment of a second and the users screen locker appears above it. The system does not hibernate. The user typically then enter its password into the screen saver and returns to the desktop seeing the previous dialog asking for root permissions to hibernate. After entering the root password, the machine hibernates and switches off. After turning power on and resuming, the users desktop is shown without asking a password. Probably because I entered the password into the screen saver right before hibernating. Version-Release number of selected component (if applicable): kde-workspace-4.11.1-3.fc19.x86_64 How reproducible: Always Steps to Reproduce: 1. Log into KDE 2. Select "Hibernate" from KDE menu 3. Enter your user password into screen saver 4. Enter root password into dialog asking for hibernate permission. Actual results: After resume you will get a system without requiring password. Expected results: Ask for password after resuming Additional info:
Could you please verify whether in System Settings -> Power Management -> Advanced Settings, the option "Lock screen on resume" is checked?
note: > 4. Enter root password into dialog asking for hibernate permission. This is not usually required, but is likely occurring because there are other active users on the computer at the time of hibernate action being requested. Can you verify if this is the case? Also: > 3. Enter your user password into screen saver I suspect this is likely the confusion here. *This* is the lock screen you want. Seems hibernate is happening too slow on your system, giving you enough time to unlock before hibernate actually finishes.
In (In reply to Dan Vrátil from comment #1) > Could you please verify whether in System Settings -> Power Management -> > Advanced Settings, the option "Lock screen on resume" is checked? Yes, "Lock screen on resume" is checked. I think in preparation for suspend KDE does two things in parallel: a. Ask for root permission to do the hibernate b. lock the screen in preparation for resume due to the above settings. However, because of b. the user is unable to answer a. So therefore he unlocks b. by giving his password. Then he sees a. and allows the suspend. Then the machine suspends and b. is actually already opened. So if I am right, I propose to start with a. and only if the permission to suspend is granted it should actually suspend and start b. In (In reply to Rex Dieter from comment #2) I booted the machine, logged into KDE and selected "hibernate". No one else is logged in and nothing else has been done. And it is not a question of speed (neither user nor system). If I wait a few minutes between my actions nothing changes.
I think the issue here is that ksmserver simply does not expect hibernating to require user interaction.
... or this may very well be another dupe of the heisenbug, https://bugzilla.redhat.com/show_bug.cgi?id=983110
Still present in fedora 20...
This sounds very similar to the bug I reported in 1191811, and may be related. I'm also running Fedora 20.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora 'version' of '20'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 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 this bug is closed as described in the policy above. 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 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.