GNOME Bugzilla – Bug 654746
Does not actually lock screen, unlock dialog takes several minutes to appear
Last modified: 2014-08-20 20:23:49 UTC
When the screen is "locked", the mouse pointer still changes (pointer/cursor/hand/etc) as if the system was unlocked and keyboard input still goes to the windows "behind" the lock screen. In other words, the system isn't locked, just hidden. The password dialog can take several minutes to appear, during which time input is still being sent to other applications. Typing password before the lock dialog appears sometimes works, other times sends your password to other applications (such as IRC client). This is 100% reproducible on my system and the time it takes the unlock dialog to appear seems directly related to the amount of time the system has been locked, ie, morning (after being locked all night) it can take over 10 minutes. System is AMD Neo X2 with 4gig RAM and r600 GPU with recent Gallium3d driver. Gentoo Linux 2.6.39 installed from Gnome overlay. Gnome 3 works in all other areas.
I can confirm this happening, although the problem only occurs occasionally. I couldn't identify the trigger so far. System is Arch Linux, 2.6.39 (.38 before), GMA4500HD intel onboard graphics.
This is a big issue, please see https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/390989 // Johan Ryberg
Arc, Tanuva, what version of gnome-screensaver ?
3.4.4-1 here. Still the same symptoms and surroundings. The last time I had such an issue, killing gnome-shell helped to get access again, not gnome-screensaver...
3.0.x and 3.2.x here, haven't upgraded to 3.4 yet. This problem seems to come up more frequently in multi-monitor mode, instead of the dialog popping up I'll get one screen covered in background, the other black, and the cursor will change to text input where the dialog should be. Typing in password (without dialog) unlocks it in those cases. I haven't had the problem of my password being sent to an hidden window (eg, IRC client) while the screen was supposedly locked but without unlock dialog showing up since 3.0.x.
if one of you could run pkill -f gnome-screensaver; gnome-screensaver --debug >& screensaver.log in a terminal in the morning and then attach the log when the problem manifiests, that would be great.
The root cause is mentioned in the launchpad bug: https://wiki.ubuntu.com/DebuggingScreenLocking#Screen_is_shown.2C_and_then_screensaver_activates_again The problem is easy to reproduce: 1. Open an rdesktop window 2. run in a terminal: sleep 3; gnome-screensaver-command -a 3. Focus rdesktop window before sleep timer runs out Or here's another of my favourite methods, which affects me every day if I'm not careful: 1. Use synergy, and move the mouse off screen to control another system via synergy. 2. Close laptop lid, where system is configured to lock after lid closes 3. Open lid, notice that screen is not locked. I'll attach a log from gnome-screensaver during the failed lock attempt, as requested by Ray. I was obligated to direct a representative in the Corporate Security group at work to this bug during a conversation about deployment of Linux desktops. It was pretty embarrassing since I've otherwise been quite a vocal advocate of Linux.
Created attachment 223463 [details] gnome-screensaver debug output during failed lock
Unfortunately, the mechanism for locking the screen is also used by things like rdesktop (it's called a grab). There's currently no way to lock the screen in this case, since these programs have already effectively taken the lock themselves. There is work undergoing in the X server to make it possible to fix this: http://fedoraproject.org/wiki/Features/Grab_override It's not ready to use yet though.
The screen lock is now implemented directly in gnome-shell, not in gnome-screensaver (as it was with older version of GNOME 3 and GNOME 2.x). If the reported problems persists in recent versions of GNOME, please file a new bug against gnome-shell with the "lock-screen" component selected. If your installation is an older version of GNOME that cannot be upgraded (such as an enterprise version), please use the appropriate support mechanism from your vendor, or your distribution instead.