GNOME Bugzilla – Bug 665701
Gnome 3.2.1 locks screen after successful login
Last modified: 2012-03-09 10:55:14 UTC
Hi, I'm experiencing issue that after successful login screen is locked and I have to input password again. Steps: 1. Login correctly using GDM. 2. Desktop is displayed and after a few seconds the screen is fading and then locked. 3. Move mouse etc. 4. Screen locked dialog with password prompt is displayed. Actual results: screen is locked immediately after successful login. Expected results: screen is unlocked immediately after successful login. I observe this issue on Gentoo (Gnome 3.2 recently in portage) and on Fedora 16. This seems to be configuration related (if I login with the different user which has no Gnome configuration, I don't observe this issue). But this seems common to several independent systems (arch linux https://bbs.archlinux.org/viewtopic.php?id=129749, my gentoo and fedora systems). If you need any additional information, I'm ready to provide it. Oleg
Gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=393451
I have experienced the same issue several times on Fedora 16 (GNOME 3.2.1). Immediately after login from gdm, the screen saver locks the screen again.
*** Bug 669515 has been marked as a duplicate of this bug. ***
I looked into this a bit today, and have a theory which I wrote on IRC and I'll paste here: <halfline> airlied: i have a theory about the screenlock thing <halfline> the IDLETIME sync counter only gives notifications when crossing a specific threshold <halfline> it tells us after we've been idle foo seconds with a "positive transition" and tells us once we're active again with a "negative transition" <halfline> so we'll never actually get a negative transition until we get a positive transition <-- muelli has quit (Ping timeout: 600 seconds) <halfline> now, gnome-session exports a dbus api to forcefully set its status to IDLE <halfline> which gnome-shell gleefully uses based on what the status was at log out time <halfline> so as soon as gnome-shell is started, it tells gnome-session "dconf says the user is idle!" <halfline> gnome-session says "okay announcing that to the world" <halfline> gnome-screensaver hears the announcement and says "time to lock!" <halfline> and even though your moving the mouse around <halfline> it doesn't do anything because the sync counter never hit its positive threshold <halfline> so we'll never hit its negative threshold <halfline> two fixes i can think of 1) don't save and restore idle status (why are we doing that?!) 2) make gnome-screensaver look at motion events itself during the fade out instead of relying exclusively on the IDLETIME counter
happens quite often there (fedora devel) I usually quit GNOME via /sbin/init 6 in a term (since it was decided users didn't need to reboot from the shell menu, even though I do need to reboot regularly)
I think this analysis is correct. To verify, set gsettings set org.gnome.shell saved-session-presence 3 and then log out and back in again. You will notice that the screensaver kicks in right after login (because the shell 'restores' the session state of 3 = idle). This seems clearly a gnome-shell bug. It should not do that.
Created attachment 208897 [details] [review] userMenu: Do not save/restore IDLE session status When restoring the previous sesssion presence, we forcefully set gnome-session's status. In the case of IDLE, this will trigger the screensaver, which is clearly unwanted first thing after login. We should only save and restore statuses that are explicitly set by the user anyway, so limit presence saving to AVAILABLE and BUSY statuses.
Review of attachment 208897 [details] [review]: Makes sense.
Attachment 208897 [details] pushed as a901f2d - userMenu: Do not save/restore IDLE session status
*** Bug 671265 has been marked as a duplicate of this bug. ***
*** Bug 671692 has been marked as a duplicate of this bug. ***