Unable to unlock the screensaver

This has been my experience following hardy upgrades on 2008-01-11.

I suspect this is a duplicate of #131679

Some debug information:
[gs_manager_request_unlock] gs-manager.c:1586 (15:48:01): Request unlock but dialog is already up
[error_watch] gs-window-x11.c:850 (15:48:02): command error output: [auth_message_handler] gnome-screensaver-dialog.c:219 (15:48:02): Got message style 1: 'Wachtwoord: '

[gs_manager_request_unlock] gs-manager.c:1586 (15:48:02): Request unlock but dialog is already up
[gs_window_raise] gs-window-x11.c:627 (15:48:02): Raising screensaver window
[gs_window_raise] gs-window-x11.c:627 (15:48:02): Raising screensaver window
[gs_window_raise] gs-window-x11.c:627 (15:48:02): Raising screensaver window
[gs_window_raise] gs-window-x11.c:627 (15:48:02): Raising screensaver window
[gs_window_xevent] gs-window-x11.c:698 (15:48:02): not raising our windows
[gs_window_xevent] gs-window-x11.c:698 (15:48:02): not raising our windows
[gs_window_xevent] gs-window-x11.c:698 (15:48:02): not raising our windows
[gs_manager_request_unlock] gs-manager.c:1586 (15:48:02): Request unlock but dialog is already up
[lock_command_watch] gs-window-x11.c:1323 (15:48:02): command output: WINDOW ID=52428803

[error_watch] gs-window-x11.c:850 (15:48:02): command error output: [gs_lock_plug_enable_prompt] gs-lock-plug.c:948 (15:48:02): Setting prompt to: Wachtwoord:

[gs_window_xevent] gs-window-x11.c:679 (15:48:02): not raising our windows
[gs_window_raise] gs-window-x11.c:627 (15:48:02): Raising screensaver window
[gs_window_xevent] gs-window-x11.c:679 (15:48:02): not raising our windows
[gs_window_xevent] gs-window-x11.c:679 (15:48:02): not raising our windows
[error_watch] gs-window-x11.c:850 (15:48:04): command error output: [request_response] gnome-screensaver-dialog.c:147 (15:48:04): got response: -2

[listener_remove_ref_entry] gs-listener-dbus.c:748 (15:48:08): removing throttler from Power screensaver for reason 'Scherm-DPMS ingeschakeld' on connection :1.4
[listener_check_throttle] gs-listener-dbus.c:454 (15:48:08): Checking for throttle
[gs_listener_set_throttle] gs-listener-dbus.c:441 (15:48:08): Changing throttle status: 0
[listener_dbus_handle_system_message] gs-listener-dbus.c:1481 (15:48:15): obj_path=/org/freedesktop/ConsoleKit/Session1 interface=org.freedesktop.ConsoleKit.Session method=ActiveChanged destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:1537 (15:48:15): ConsoleKit notified ActiveChanged 0
[listener_add_ref_entry] gs-listener-dbus.c:723 (15:48:15): adding throttler from ConsoleKit for reason 'Session is not active' on connection :1.4
[listener_check_throttle] gs-listener-dbus.c:454 (15:48:15): Checking for throttle
[list_ref_entry] gs-listener-dbus.c:380 (15:48:15): throttler: ConsoleKit for reason: Session is not active
[gs_listener_set_throttle] gs-listener-dbus.c:441 (15:48:15): Changing throttle status: 1
Afgesloten

I have this same problem. After a restore from hibernate, the screen saver gets activated by a pause in activity and it is not possible to unlock the screen. This started happening after the update of the tzdata package. For some reason, this package is not saved in the cache, nor can I access it to downgrade using synaptic. However, the combination of symptoms may help to debug this problem by figuring out why tzdata affects the screen saver.

Today on Intrepid I had this bug twice: The prompt box for password was never shown!
I had to kill gnome-screensaver.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu intrepid (development branch)
Release: 8.10
Codename: intrepid
$ uname -a
Linux ubuntu 2.6.27-7-generic #1 SMP Fri Oct 10 03:55:24 UTC 2008 i686 GNU/Linux
$ gnome-screensaver --version
gnome-screensaver 2.24.0

I too am having this issue in the latest intrepid. will send more details when it occurs again. is is possible to raise the importance of this. normal users will not know what to do when this occurs and probably just reboot and loose all their data

I am getting this issue since I have moved to 8.10. I have noticed that the checking does seem to take longer and just when I think I am going to have to retype my password I get in. If it hangs on checking I can kill X with ctrl-backspace. I haven't checked if I could switch to a terminal and kill screensaver.

It happened to me again this morning. I was able to go to console and kill gnome-screensaver. When i got back to the gui I had to still kill a crashed window of gnome-screensaver (it was just a white block). To be able to lock my screen again I had to also start gnome-screensaver again via cli. Funny enough when I got back to my desk I was able to then unlock. So this is very random and in a corporate env where i have to lock my screen 10 times a day it's ridiculous to have to do all of this.

confirming based on the comments of users.

I haven't had this issue for a while now, seems fixed for me. and I lock my pc daily about 10 times and not once in the last 3 weeks

I am still getting this. The password checking box eventually goes away and I get back to my desktop. It can take a couple of minutes. When I get back I notice that the load average monitor is full so it appears as if something is hogging the machine and that is causing the screen-saver not to disappear. How can I tell after getting back in what was hogging the CPU?
Ray

This bug still occurs for me today...

Confirmed, exactly as described in above posts.
gnome-screensaver 2.24.0-0ubuntu2

Same issue here.

It doesn't always happen -- just sometimes.

It seems to only ever happen the first time I lock the screen for any given day. If I don't log out and in again, it doesn't seem to happen again.

I used to see this on Hardy. I moved to Intrepid a few months back and wasn't seeing this bug until this week.

Interestingly, this always happens when I enter a *wrong* password once at the gnome-screensaver password prompt:
- Lock screen (settings: blank screen, lock when screensaver active).
- Enter wrong password.
- It comes back with the password prompt with a message that the password was incorrect.
- I enter the password again (doesn't matter if its correct/wrong).
- Boom - it hangs there with the 'Checking' message.

Switching to the terminal shows gnome-screensaver using 100% cpu. I've previously just killed gnome-screensaver and moved on, though it looks like it recovers after a long time.

This happens all the time - the magic is to enter a wrong password once/twice at the password prompt.
I'm on Intrepid with latest updates. T61p with nVidia Quadro 570M GPU - 180.29 drivers.

Update: Looking at the logs, I might have found *where* the problem is. The relevant part of auth.log:

Mar 11 18:00:09 xyz-tp unix_chkpwd[8968]: password check failed for user (naveen)
Mar 11 18:00:09 xyz-tp gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=naveen
Mar 11 18:00:10 xyz-tp gnome-screensaver-dialog: gkr-pam: unlocked 'login' keyring
Mar 11 18:00:14 xyz-tp unix_chkpwd[8972]: password check failed for user (naveen)
Mar 11 18:00:14 xyz-tp gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=naveen
Mar 11 18:00:14 xyz-tp gnome-screensaver-dialog: gkr-pam: unlocked 'login' keyring
Mar 11 18:00:20 xyz-tp unix_chkpwd[8976]: password check failed for user (naveen)
Mar 11 18:00:20 xyz-tp gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=naveen
Mar 11 18:08:53 xyz-tp login[8880]: pam_sm_authenticate: Called
Mar 11 18:08:53 xyz-tp login[8880]: pam_sm_authenticate: username = [naveen]
Mar 11 18:08:53 xyz-tp login[8880]: Error attempting to parse .ecryptfsrc file; rc = [-5]
Mar 11 18:08:53 xyz-tp login[8880]: Unable to read salt value from user's .ecryptfsrc file; using default
Mar 11 18:08:53 xyz-tp login[9007]: Error attempting to open [/home/naveen/.ecryptfs/wrapped-passphrase] for reading
Mar 11 18:08:53 xyz-tp login[9007]: Error attempting to unwrap passphrase from file [/home/naveen/.ecryptfs/wrapped-passphrase]; rc = [-5]
Mar 11 18:08:54 xyz-tp login[9007]: Error adding passphrase key token to user session keyring; rc = [-5]
Mar 11 18:08:54 xyz-tp login[8880]: pam_unix(login:session): session opened for user naveen by naveen(uid=0)
Mar 11 18:10:40 xyz-tp login[8880]: pam_unix(login:session): session closed for user naveen
Mar 11 18:10:49 xyz-tp gnome-screensaver-dialog: gkr-pam: unlocked 'login' keyring

In this case, I entered wrong password thrice - the first two times, gnome-screensaver quickly came back with the prompt. The third time, it hung with the 'Checking' message. If we look at the logs above, we can see three log messages associated with each attempt: a "unix_chkpwd" messag...

Logs from a good session: (messages)

Mar 18 10:39:20 nacmacfeegle gnome-screensaver-dialog: pam_sm_authenticate: Called
Mar 18 10:39:20 nacmacfeegle gnome-screensaver-dialog: pam_sm_authenticate: username = [berend.deschouwer]
Mar 18 10:39:20 nacmacfeegle gnome-screensaver-dialog: Error attempting to parse .ecryptfsrc file; rc = [-5]
Mar 18 10:39:20 nacmacfeegle gnome-screensaver-dialog: Unable to read salt value from user's .ecryptfsrc file; using default
Mar 18 10:39:21 nacmacfeegle gnome-screensaver-dialog: Passphrase key already in keyring
Mar 18 10:39:21 nacmacfeegle gnome-screensaver-dialog: There is already a key in the user session keyring for the given passphrase.

Logs from a good session (auth.log)

Mar 18 10:39:17 nacmacfeegle gnome-screensaver-dialog: pam_lwidentity(gnome-screensaver:auth): PAM config: global:krb5_cca
che_type 'FILE'
Mar 18 10:39:17 nacmacfeegle gnome-screensaver-dialog: pam_lwidentity(gnome-screensaver:auth): failed to get GP info
Mar 18 10:39:17 nacmacfeegle gnome-screensaver-dialog: pam_lwidentity(gnome-screensaver:auth): getting password (0x0000000
0)
Mar 18 10:39:20 nacmacfeegle gnome-screensaver-dialog: pam_lwidentity(gnome-screensaver:auth): request failed
Mar 18 10:39:20 nacmacfeegle gnome-screensaver-dialog: pam_lwidentity(gnome-screensaver:auth): User 'berend.deschouwer' is
 not known.
Mar 18 10:39:21 nacmacfeegle gnome-screensaver-dialog: pam_lwidentity(gnome-screensaver:account): PAM config: global:krb5_
ccache_type 'FILE'
Mar 18 10:39:21 nacmacfeegle gnome-screensaver-dialog: pam_lwidentity(gnome-screensaver:account): request failed
Mar 18 10:39:21 nacmacfeegle gnome-screensaver-dialog: pam_lwidentity(gnome-screensaver:account): User 'berend.deschouwer'
 is not known.
Mar 18 10:39:21 nacmacfeegle gnome-screensaver-dialog: pam_lwidentity(gnome-screensaver:account): Returning 7 for user "be
rend.deschouwer"
Mar 18 10:39:21 nacmacfeegle gnome-screensaver-dialog: pam_lwidentity(gnome-screensaver:setcred): PAM config: global:krb5_
ccache_type 'FILE'
Mar 18 10:39:21 nacmacfeegle gnome-screensaver-dialog: pam_lwidentity(gnome-screensaver:setcred): request failed
Mar 18 10:39:21 nacmacfeegle gnome-screensaver-dialog: pam_lwidentity(gnome-screensaver:setcred): User 'berend.deschouwer'
 is not known.

Logs from a bad session (messages)

Mar 18 09:54:15 nacmacfeegle gnome-screensaver-dialog: pam_sm_authenticate: Called
Mar 18 09:54:15 nacmacfeegle gnome-screensaver-dialog: pam_sm_authenticate: username = [berend.deschouwer]
Mar 18 09:54:15 nacmacfeegle gnome-screensaver-dialog: Error attempting to parse .ecryptfsrc file; rc = [-5]
Mar 18 09:54:15 nacmacfeegle gnome-screensaver-dialog: Unable to read salt value from user's .ecryptfsrc file; using default
Mar 18 09:54:18 nacmacfeegle kernel: [ 2321.178490] [fglrx] It's not necessary to adjust system aperture on this ASIC
Mar 18 09:54:23 nacmacfeegle kernel: [ 2326.208849] ecryptfs_parse_options: eCryptfs: unrecognized option 'rw'
Mar 18 09:54:23 nacmacfeegle kernel: [ 2326.208858] ecryptfs_parse_options: eCryptfs: unrecognized option 'user=berend.deschouwer'

Logs from a bad session (auth.log)

Mar 18 09:54:11 nacmacfeegle gnome-screensaver-dialog: pam_...

Upgraded to Jaunty Alpha/beta. The problem went away for a week, but now it's back.

I can confirm this behaviour on both intrepid and jaunty.

The behaviour initially started after enabling automatic user login (in Administration->Login Window) although now it seems to not go away.

The problem is sporadic, affecting me around 50% of the time at present.

I've had this occasionally with Jaunty, including just now. gnome-screensaver was taking up 99% of CPU while it 'checked my password'. Killing gnome-screensaver didn't work - the X window didn't redraw itself, but just stayed stuck on a black screen with a white box where the 'Checking your password' window used to be. I had to reboot.

I had also just enabled automatic user login and then disabled it, similarly to what chrism2671 noted.

I've never activated autologin, despite this I've been expereincing this bug since Intrepid on a odd basis.

I'm having system hang on trying to unlock screen, after a requested lock, -probably- only when I miss-enter password. It says "checking" and the little "busy/wait' symbol spins, and spins and .... I once tried waiting 5 minutes before resetting hardware. It only began happening on this box after upgrading to 9.04. This MAY NOT be consistent behavior. I've seen it take longer than I think reasonable (several seconds intentional delay?) on offering a second try at password entry, BUT that may have been on resuming after "Suspend", rather than "Lock Screen".

What I've been seeing seems an exact fit to descriptions of Lunchpad bug #314545, so I've reported it there, TOO.

I've been seeing this bug in Karmic for a long time. Ctrl-alt-backspace does NOT kill X. Ctrl-alt-delete does NOT reboot.

This bug (or a very similar bug) is alleged to have been fixed for Lucid (bug #524860).

I've noticed whenever this happens that 'ps ax' lists _two_ instances of gnome-screensaver-dialog. If I kill both and let the dialog respawn, then only one is listed and I'm able to log in again.

Stopped for me in Lucid.

The description matches what happens on my Dell Mini 9 with Ubuntu 10.10 (fresh install, not update).

I occasionally use an external monitor, but this also happens after a cold start with no monitor attached. I have auto-login enabled. I have set up an ecryptfs encrypted directory manually.

I think I might have pinpointed the cause of this one (or at least, *one* cause), and it's a weird one:

I was having this same issue, and it has since gone away, and I failed to pinpoint what exactly made things change -- until Antti Kaihola's comment (number 28, above) made me remember. I had an ecryptfs directory whose passphrase was different than my login passphrase. Once I made the two passphrases the same -- voila! No more login window freezes.

What's more, during the timeframe where I had the non-matching passphrases, I had noticed another strange behavior: if I logged into the console (via tty1/tty2/etc.), I would then have to logout *twice*! The first logout would just clear the screen and bring up another shell prompt, and only the second logout would "stick".

Whether these two things (the screensaver freeze, and the double-logout) are causally related, I don't know. But it's worth putting the info out there, I suppose.

Anyway, as I said, making the passphrases match cleared up both problems.

Re Omer Preminger #29: My ecryptfs password matches my login passphrase, so I must have a different reason for the screensaver problem.

The are a variety of reasons why gnome-screensaver is not unlocking, and I suspect you each have a different reason.
I am closing this bug, as there is no way to diagnose it.

There are some debugging tips here: https://wiki.ubuntu.com/DebuggingScreenLocking

If you still have unlocking issues with a recent release of Ubuntu, please file a new bug.

Thanks.