GNOME Bugzilla – Bug 684172
Sometimes no password prompt at unlock screen
Last modified: 2014-11-09 17:28:12 UTC
Created attachment 224473 [details] backtrace of shell in the broken state Running gnome-shell-3.5.91-1.fc18.x86_64 . Sometimes (not sure what the circumstances are), I get no password prompt at the new-style unlock screen. I hit 'Esc' or drag the screen up and I just get a grey screen, no prompt. The panel at the top of screen appears to work correctly so it's not like it's hung, but it's not creating the prompt for some reason. I can't find any way around this besides switching to a VT and killing shell and restarting it. I'm attaching a gdb trace of gnome-shell while it's doing this (I reproduced the bug and attached gdb to shell from a VT). Hope it helps figure out what's going on.
Is there anything in ~/.xsession-errors or ~/.cache/gdm/session.log?
Nothing in .xsession-errors, but when running Shell from a terminal, I see these errors at the time I hit 'esc': JS ERROR: !!! Failed to open reauthentication channel JS ERROR: !!! message = '"GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No sessions for adamw available for reauthentication"' JS ERROR: !!! fileName = '"/usr/share/gnome-shell/js/gdm/util.js"' JS ERROR: !!! lineNumber = '142' JS ERROR: !!! stack = '"0 anonymous("result" = [object _private_Gio_SimpleAsyncResult], "client" = [object _private_Gdm_Client])@/usr/share/gnome-shell/js/gdm/util.js:142 1 wrapper([object _private_Gdm_Client], [object _private_Gio_SimpleAsyncResult])@/usr/share/gjs-1.0/lang.js:204 "' Window manager warning: Log level 8: gtk_im_context_reset: assertion `GTK_IS_IM_CONTEXT (context)' failed Window manager warning: Log level 8: gtk_im_context_set_client_window: assertion `GTK_IS_IM_CONTEXT (context)' failed so possibly something with Fedora session management? On my current boot, btw, this bug seems to be happening 100% of the time I lock the screen. I'm available for debugging in #fedora-desktop at present and I'll try to keep this boot up so I can reproduce at will.
I hit this a number of times too with 3.5.91...an interesting thing is in that scenario using "loginctl unlock-session 1" as root from a VT gave me back the unlocked desktop again.
So I guess I can see why this would happen if I'm launching gnome-shell from a VT, as I have to do after the first time it happens (to escape the broken state I go to a VT and do 'DISPLAY=:0 gnome-shell --replace'). I guess in that case the shell process becomes part of the session associated with the VT login, not part of the session associated with the rest of GNOME. Right? loginctl shows three sessions for 'adamw', which I'm figuring are the graphical desktop on VT1, and my two logins on VT2 and VT3. loginctl session-status of course shows the gnome-shell process in the CGroup for the VT2 session, not the VT1 session. So that kinda hooks up. But it doesn't explain why I hit this the *first* time, when Shell is running with the rest of the session. of course, I could be misunderstanding things. I guess I'll reboot and poke it when the problem happens again.
of course, the *very next time* the lock screen showed up, the unlock dialog worked. even though Shell is running from VT2. so that's that theory up in smoke...
GDM looks at all sessions for a given user under the same seat as the calling process, not only the same session as the caller. You should look at "loginctl show-seat seat0" and "loginctl show-session ...", the session should be Type=x11 and State=active. Also, try running GDM with debug enabled, and keep an eye in the journal.
I definitely hit this one as well on my laptop (current F18, same gnome-shell version as Adam). I will try to collect the infos from #6 and report back.
Me too. Right now it's not happening to me. One piece of data that may be relevant is that I'm using revelation, which I think does some fairly odd things to its windows, especially its database unlock dialog. It's possible this is part of the issue, I guess. It's hard for me to run without revelation to confirm this, though, as it has all my passwords in it =)
I don't have revelation installed here and I still triggered it a couple of times so it has to be something else. I haven't yet been able to reproduce it though.
So I was able to reproduce this after closing the laptop lid and opening it back again fairly quickly. Now I have a box with the grey background and with no password prompt. I will be uploading the debug gdm logs to this BZ together with ~/.xsession-errors and ~/.cache/gdm/session.log $ loginctl show-seat seat0 Id=seat0 ActiveSession=26 CanMultiSession=yes CanTTY=yes CanGraphical=yes Sessions=26 2 IdleHint=no IdleSinceHint=1348047644453001 IdleSinceHintMonotonic=12744411196 $ loginctl show-session 2 Id=2 Timestamp=Tue, 18 Sep 2012 16:05:39 +0200 TimestampMonotonic=42318586 DefaultControlGroup=name=systemd:/user/michele/2 VTNr=1 Display=:0 Remote=no Service=gdm-password Leader=1473 Audit=2 Type=x11 Class=user Active=no State=closing KillProcesses=no IdleHint=yes IdleSinceHint=1348047418651508 IdleSinceHintMonotonic=12521844620 Name=michele In terms of journal entries here are the relevant lines: DEBUG(+): GdmSessionWorker: state ACCREDITED DEBUG(+): GdmSessionWorker: pid 1720 reauthenticated user 1000 with service 'gdm-password' DEBUG(+): GdmSession: Closing session DEBUG(+): GdmSession: Stopping all conversations DEBUG(+): GdmSessionWorkerJob: Stopping job pid:4786 DEBUG(+): GdmCommon: sending signal 15 to process 4786 DEBUG(+): GdmSessionWorkerJob: Waiting on process 4786 dbus[656]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.2" (uid=0 pid=637 comm="/usr/lib/systemd/systemd-logind ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.42" (uid=1000 pid=1485 comm="gnome-session ") [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.2" (uid=0 pid=637 comm="/usr/lib/systemd/systemd-logind ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.42" (uid=1000 pid=1485 comm="gnome-session ") DEBUG(+): GdmCommon: process (pid:4786) done (signal:15) DEBUG(+): GdmSessionWorkerJob: SessionWorkerJob died DEBUG(+): GdmSession: Emitting 'reauthenticated' signal DEBUG(+): GdmSimpleSlave: trying to migrate session DEBUG(+): GdmSlave: Activating session: '2' DEBUG(+): GdmSlave: unable to activate session: 2 pam_unix(su-l:session): session closed for user root Lid closed. dbus[656]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.2" (uid=0 pid=637 comm="/usr/lib/systemd/systemd-logind ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.45" (uid=1000 pid=1684 comm="/usr/libexec/gnome-settings-daemon ") [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.2" (uid=0 pid=637 comm="/usr/lib/systemd/systemd-logind ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.45" (uid=1000 pid=1684 comm="/usr/libexec/gnome-settings-daemon ") dbus[656]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.2" (uid=0 pid=637 comm="/usr/lib/systemd/systemd-logind ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.42" (uid=1000 pid=1485 comm="gnome-session ") [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.2" (uid=0 pid=637 comm="/usr/lib/systemd/systemd-logind ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.42" (uid=1000 pid=1485 comm="gnome-session ") Suspending system... <info> (eth0): carrier now OFF (device state 100, deferring action for 4 seconds) <info> (eth0): carrier now ON (device state 100) (upowerd:1311): UPower-Linux-WARNING **: unknown status string: System resumed. Service sleep.target is not needed anymore. Stopping. dbus[656]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.67" (uid=1000 pid=1720 comm="/usr/bin/gnome-shell ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.6" (uid=0 pid=673 comm="/usr/sbin/gdm-binary ") [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.67" (uid=1000 pid=1720 comm="/usr/bin/gnome-shell ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.6" (uid=0 pid=673 comm="/usr/sbin/gdm-binary ") gdm-binary[673]: DEBUG(+): GdmManager: trying to open reauthentication channel for user michele DEBUG(+): GdmManager: trying to open reauthentication channel for user michele gdm-binary[673]: DEBUG(+): GdmManager: There are no applicable sessions (1 looked at) DEBUG(+): GdmManager: There are no applicable sessions (1 looked at) dbus[656]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper) dbus[656]: [system] Successfully activated service 'org.freedesktop.PackageKit' [system] Successfully activated service 'org.freedesktop.PackageKit' New session 26 of user root. AccountsService-DEBUG(+): ActUserManager: ignoring tty session '26' since it's not graphical: Success pam_unix(login:session): session opened for user root by LOGIN(uid=0) ROOT LOGIN ON tty2 AccountsService-DEBUG(+): ActUserManager: ignoring tty session '26' since it's not graphical: Success AccountsService-DEBUG(+): ActUserManager: ignoring unspecified session '27' since it's not graphical: Success (root) CMD (/usr/lib64/sa/sa1 1 1) AccountsService-DEBUG(+): ActUserManager: ignoring tty session '26' since it's not graphical: Success AccountsService-DEBUG(+): ActUserManager: ignoring unspecified session '27' since it's not graphical: Success AccountsService-DEBUG(+): ActUserManager: ignoring tty session '26' since it's not graphical: Success DHCPREQUEST on eth0 to 172.16.11.254 port 67 (xid=0x2abcab8e) DHCPACK from 172.16.11.254 (xid=0x2abcab8e) bound to 172.16.11.100 -- renewal in 3052 seconds. <info> (eth0): DHCPv4 state changed renew -> renew <info> address 172.16.11.100 <info> prefix 24 (255.255.255.0) <info> gateway 172.16.11.254 <info> nameserver '172.16.11.254' <info> domain name 'int.rhx' [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) dbus[656]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) dbus[656]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Do let me know if there are other commands you'd like to run as I still have the box in this state next to me.
Created attachment 224723 [details] File: /home/michele/.cache/gdm/sessionlog
Created attachment 224724 [details] xsession-errors
Created attachment 224725 [details] gdm debug log files /var/log/gdm
Your session is marked "closing", yet X is up an running, and so are the session worker and simple slave (if I read the logs correctly). Try loginctl session-status 2, and look at the session leader, check if it is still alive. If so, this is a logind problem. Otherwise, something's crashing without a backtrace. Try also systemctl status gdm and look at what processes are in the cgroup.
loginctl session-status 2: 2 - michele (1000) Since: Tue, 18 Sep 2012 16:05:39 +0200; 21h ago Leader: 1473 (gdm-session-wor) Seat: seat0; vc1 Display: :0 Service: gdm-password; type x11; class user State: closing CGroup: name=systemd:/user/michele/2 ├ 1473 gdm-session-worker [pam/gdm-password] ├ 1482 /usr/bin/gnome-keyring-daemon --daemonize --login ├ 1485 gnome-session ├ 1494 dbus-launch --sh-syntax --exit-with-session ├ 1495 /bin/dbus-daemon --fork --print-pid 5 --print-addr... ├ 1557 /usr/libexec/imsettings-daemon ├ 1560 /usr/libexec/gvfsd ├ 1564 /usr/libexec//gvfsd-fuse -f /run/user/1000/gvfs ├ 1568 /usr/lib64/xfce4/xfconf/xfconfd ├ 1663 /usr/libexec/at-spi-bus-launcher ├ 1667 /bin/dbus-daemon --config-file=/etc/at-spi2/access... ├ 1671 /usr/libexec/at-spi2-registryd --use-gnome-session... ├ 1684 /usr/libexec/gnome-settings-daemon ├ 1690 /usr/bin/pulseaudio --start ├ 1698 /usr/libexec/pulse/gconf-helper ├ 1700 /usr/libexec/gconfd-2 ├ 1705 /usr/libexec/gvfs-udisks2-volume-monitor ├ 1709 /usr/libexec/gvfs-gphoto2-volume-monitor ├ 1713 /usr/libexec/gvfs-afc-volume-monitor ├ 1720 /usr/bin/gnome-shell ├ 1735 nm-applet ├ 1736 /usr/libexec/evolution/3.6/evolution-alarm-notify ├ 1737 /usr/libexec/deja-dup/deja-dup-monitor ├ 1741 /usr/libexec/tracker-store ├ 1742 /usr/libexec/tracker-miner-fs ├ 1745 /usr/libexec/gsd-printer ├ 1749 zeitgeist-datahub ├ 1754 /usr/libexec/dconf-service ├ 1798 /usr/bin/zeitgeist-daemon ├ 1830 /usr/libexec/zeitgeist-fts ├ 1839 /bin/cat ├ 1847 /usr/libexec/evolution-source-registry ├ 1849 /usr/libexec/mission-control-5 ├ 1862 /usr/libexec/goa-daemon ├ 1865 /usr/libexec/gnome-shell-calendar-server ├ 1882 /usr/libexec/evolution-calendar-factory ├ 1931 /usr/libexec/telepathy-logger ├ 1938 /usr/libexec/evolution-addressbook-factory ├ 1950 gnome-terminal ├ 1956 gnome-pty-helper ├ 1957 -bash ├ 21045 /usr/bin/python /usr/bin/zim └ 21046 /usr/bin/python /usr/bin/zim Leader seems alive (also all the other pids at least exist on the system): root 1473 0.0 0.1 502272 5140 ? Sl Sep18 0:00 \_ gdm-session-worker [pam/gdm-password] systemctl status gdm: gdm.service - GNOME Display Manager Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled) Active: active (running) since Tue, 18 Sep 2012 16:05:21 +0200; 21h ago Main PID: 673 (gdm-binary) CGroup: name=systemd:/system/gdm.service ├ 673 /usr/sbin/gdm-binary ├ 737 /usr/libexec/gdm-simple-slave --display-id /org/gn... ├ 768 /usr/bin/Xorg :0 -br -verbose -logverbose 7 -core ... └ 1473 gdm-session-worker [pam/gdm-password] DEBUG(+): GdmSession: Emitting 'reauthentication-started' signal for caller pid '1720' DEBUG(+): GdmSimpleSlave: reauthentication started DEBUG(+): GdmSession: Emitting 'reauthenticated' signal DEBUG(+): GdmSimpleSlave: trying to migrate session DEBUG(+): GdmSlave: Activating session: '2' DEBUG(+): GdmSlave: unable to activate session: 2 gdm-binary[673]: DEBUG(+): GdmManager: trying to open reauthentication channel for user michele DEBUG(+): GdmManager: trying to open reauthentication channel for user michele gdm-binary[673]: DEBUG(+): GdmManager: There are no applicable sessions (1 looked at) DEBUG(+): GdmManager: There are no applicable sessions (1 looked at) So you reckon it is a logind issue?
I see 'closing', just like Michele, when I hit this bug. The leader process is still running. Also possibly of interest, one of my two VT logins - the one where I run DISPLAY=:0 gnome-shell - also shows as 'closing'. That's a pretty simple session with only seven processes in its CGroup.
For Fedora 18 folks, there's a systemd 190 build now available: http://koji.fedoraproject.org/koji/buildinfo?buildID=355530 Kay says 190 may possibly fix this, so we should try it out.
So far I have not been able to reproduce it (been using 190 and later on 193 systemd packages). Adam, how about you, has it happened for you with systemd >= 190?
It was still happening with 190, I think, and I actually disabled the lock screen because it was annoying me too much. Now there've been more changes to systemd, accountsservice etc I'll re-enable it and see what happens.
Oh, that's right, now I remember: I started seeing another bug, where - seemingly every time - when I enter my password and hit enter the screen simply doesn't unlock. Nothing happens. There is no way out but to kill Shell, it seems. That's why I had to disable the lock screen. Is that one known?
While with 190+ it is happening less frequent, it still may happen, especially after hibernation. Just had this again two days ago using 192. @Adam: The screen shows up, yes, but the label "Password" does not show up, so you may type your password, but it does not unlock because it is no real password prompt. You can unlock your session via console as root: systemctl --unlock-session SESSIONID
s/systemctl/loginctl/ of course.
Just a guess and not yet tested extensively (after update so far it did not occur, but this does not mean anythin), but maybe that one is related: Bug 685434 (patch for the bug already in git master).
Hi Adam, Gert, I confirm I see the same. So no more the initial issue where the screen was all gray, but I see the normal unlock screen with the Password: fiels, I type in my password and nothing happens. loginctl unlock-session <id> works This is with systemd-194-1.fc18.i686 and gnome-shell-3.6.0-1.fc18.i686
Sounds like bug 685988
Thanks Ray. I am testing with systemd-195 (I assume your patch is included in this version). Will report back
So far I have not experienced this same issue (I have noticed that very rarely gdm seems to not start at boot, needing ssh-ing to the box and restarting it but I will look into that some other time) Ok to close it from my side. Adam & others, have you experienced this again with systemd-195?
As said in my last comment, after applying the fix for Bug 685434 , I did not see this again.
I've been running with lock screen disabled for weeks now. I'll try and find time to re-enable it and check this, but i'm crazy busy with F18 validation ATM. I don't mind if this gets closed, I can always re-open if I find there are still problems.
I've seen this very recently on my machine - I'll try to reproduce again.
Still have this bug everyday on 2 different installation on a released and up-to-date version of F18. gnome-shell version is however 3.6.2-6.fc18 . Is there a need to file a new bug?
I am experiencing this problem as well. I believe it's tied to mouse control when the screen is locked. I run synergys on the my Fedora box. When my mouse in on another computer at lock time, I end up with the grey screen problem mentioned here. If the mouse in on the Fedora box at lock time, I don't experience the problem. This seem reasonably repeatable (I've lost enough work to it). :) Thanks for your hard work on this. I've disable automatic lock on my Fedora box now. I don't believe this occurs with manual locks.
(In reply to comment #32) > I am experiencing this problem as well. I believe it's tied to mouse control > when the screen is locked. This sounds like bug 689106, e.g. not failing gracefully when the pointer cannot be grabbed. The 3.6.2 release which is already in Fedora contains the fix.
I meant 3.6.3.
*** Bug 695048 has been marked as a duplicate of this bug. ***
(In reply to comment #34) > I meant 3.6.3. So is this fixed nowadays? (Symptoms in bug 662757 also sound related.)
Not on F19 with gnome-shell-3.8.4-2.fc19.i686 running, I haven't seen it.
Let's consider this fixed, as there haven't been any new cases for a year and a half.