Screen is locked again after unsuspend and successful authentication

apport information

apport information

Status changed to 'Confirmed' because the bug affects multiple users.

After using Update Manager yesterday (11/14/2011), this problem appears to be fixed. After coming out of suspend, I am presented with a login screen. Once I authenticate, I do not get an immediate re-prompt for my password.

I spoke too soon. Apparently, I wasn't really in suspend. It still does ask me to login a second time.

Hi Ursula,

Would you please take a look into this and let me know if you can find out any more information?

I just tried to reproduce on an Thinkpad X201s and was unable to do so. This might be hardware dependent.

I experience this bug reproducibly on a Thinkpad T420s. Only however if the suspend mode was initiated automatically and therefore the screen was locked at this instant. That suggests that during resume, in the attempt to restore everything, the screen lock is restarted as well since it was active when the machine went into suspend mode.

I have my personal T410 and never seen that bug. It has UMA graphics and set to suspend if Lid is closed on battery power. I will try some Dell with 11.10 and report results. Does LID closed suspending fit the bug description?

I tried on Dell Lattitude with nvidia . unity 4.22.0
I setup it go to sleep on battery power

The bug did not show up.

However I recall seeying double login not related to suspend in the past. I believe (not 100% sure) that it was gone after upgrading to proposed unity

I'm quite sure I found the reason for this behavior - A closer look at my settings showed following:

[Screen:]
Turn off after: 10 minutes
Lock Screen after: Screen turns off

[Power]
Suspend when inactive for: 10 minutes

Therefore, what most probably happens is: Both Suspend and Screen Lock are in this setting initiated at the same instant, however the Suspend mode preempts the Screen Lock and so after the systems is resumed, the Screen Lock is subsequently initiated.

If that is truely the case (I'll test) we should have gnome-settings do no screen locking in conditions where (time_to_lock == time_to_poweroff)

I tried 5 and 5 minutes, no dice. Perhaps it kicks in when lock screen is _longer_ than the suspend setting. Iirc this kind of used to be the case back in the day with xscreensaver, acpid would suspend your laptop and then when you opened it up again you would see a screen, then when xscreensaver got a timeslice it would lock your screen so you would have to log in.

Hello, would someone that can reproduce this please run this in a terminal window and attach the output here?

gnome-screensaver-command --exit
gnome-screensaver --no-daemon --debug

related to bug 908684

gnome-screensaver debug output with the bug occuring:

Weird, it looks like it gets an idle signal _right_ after login. We'll have to do some more investigating.

Looked at this more today, My guess would be the 1 second delta_notice_timeout in gs-watcher-x11.c . For some reason this causes a function to loop until it locks the screen. I'm guessing that this might be useful if the screensaver has detected it should be blanking but is unable to.

It's also interesting that from the debug log, this happened after an initial password entry failure. That may be required to encounter this problem.

For reference: http://developer.gnome.org/glib/2.30/glib-The-Main-Event-Loop.html#g-timeout-add

There is a race between gnome-screensaver fading the screen and upower suspending the computer.
You can try uncommenting the "no_fade_on_user_switch" patch to see if it goes away. This is what has been done in Precise (in 3.2.0-1ubuntu4).

"It's also interesting that from the debug log, this happened after an initial password entry failure. That may be required to encounter this problem."

The initially failed authentication does not affect the occurrence of the bug. It was merely a coincidence that this happened when I logged the debug output.

I'm not sure if I'm seeing any solution above. I'm still having problem with Ubuntu 11.10. Could anyone point me to the solution for this?

Matt

Lower the OEM Priority importance to Medium as this is not critical to our customer.

Would someone that can reproduce this bug please try uncommenting the "no_fade_on_user_switch" patch to see if it goes away?

Closing wontfix since this has been Incomplete for so long.