After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 684172 - Sometimes no password prompt at unlock screen
Sometimes no password prompt at unlock screen
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: lock-screen
3.5.x
Other Linux
: Normal major
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 695048 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-09-17 05:33 UTC by Adam Williamson
Modified: 2014-11-09 17:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
backtrace of shell in the broken state (85.96 KB, text/plain)
2012-09-17 05:33 UTC, Adam Williamson
Details
File: /home/michele/.cache/gdm/sessionlog (31.38 KB, text/x-log)
2012-09-19 09:52 UTC, Michele Baldessari
Details
xsession-errors (36.50 KB, application/octet-stream)
2012-09-19 09:52 UTC, Michele Baldessari
Details
gdm debug log files /var/log/gdm (26.21 KB, application/x-gzip)
2012-09-19 09:53 UTC, Michele Baldessari
Details

Description Adam Williamson 2012-09-17 05:33:30 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.
Comment 1 Jasper St. Pierre (not reading bugmail) 2012-09-17 05:48:00 UTC
Is there anything in ~/.xsession-errors or ~/.cache/gdm/session.log?
Comment 2 Adam Williamson 2012-09-17 16:57:04 UTC
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.
Comment 3 Cosimo Cecchi 2012-09-17 17:01:36 UTC
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.
Comment 4 Adam Williamson 2012-09-17 17:34:16 UTC
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.
Comment 5 Adam Williamson 2012-09-17 18:50:56 UTC
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...
Comment 6 Giovanni Campagna 2012-09-17 19:00:34 UTC
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.
Comment 7 Michele Baldessari 2012-09-17 20:23:14 UTC
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.
Comment 8 Adam Williamson 2012-09-17 23:49:02 UTC
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 =)
Comment 9 Michele Baldessari 2012-09-18 07:08:29 UTC
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.
Comment 10 Michele Baldessari 2012-09-19 09:50:51 UTC
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.
Comment 11 Michele Baldessari 2012-09-19 09:52:03 UTC
Created attachment 224723 [details]
File: /home/michele/.cache/gdm/sessionlog
Comment 12 Michele Baldessari 2012-09-19 09:52:40 UTC
Created attachment 224724 [details]
xsession-errors
Comment 13 Michele Baldessari 2012-09-19 09:53:44 UTC
Created attachment 224725 [details]
gdm debug log files /var/log/gdm
Comment 14 Giovanni Campagna 2012-09-19 11:31:37 UTC
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.
Comment 15 Michele Baldessari 2012-09-19 11:45:04 UTC
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?
Comment 16 Adam Williamson 2012-09-20 05:59:10 UTC
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.
Comment 17 Adam Williamson 2012-09-20 19:50:46 UTC
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.
Comment 18 Michele Baldessari 2012-10-01 22:10:50 UTC
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?
Comment 19 Adam Williamson 2012-10-01 22:17:33 UTC
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.
Comment 20 Adam Williamson 2012-10-02 02:20:54 UTC
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?
Comment 21 Gert Kulyk 2012-10-02 19:36:06 UTC
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
Comment 22 Gert Kulyk 2012-10-02 19:57:07 UTC
s/systemctl/loginctl/ of course.
Comment 23 Gert Kulyk 2012-10-03 21:12:54 UTC
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).
Comment 24 Michele Baldessari 2012-10-13 17:52:28 UTC
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
Comment 25 Ray Strode [halfline] 2012-10-15 19:37:37 UTC
Sounds like bug 685988
Comment 26 Michele Baldessari 2012-10-23 10:50:53 UTC
Thanks Ray. I am testing with systemd-195 (I assume your patch is included in this version). Will report back
Comment 27 Michele Baldessari 2012-11-06 13:38:28 UTC
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?
Comment 28 Gert Kulyk 2012-11-06 18:15:23 UTC
As said in my last comment, after applying the fix for Bug 685434 , I did not see this again.
Comment 29 Adam Williamson 2012-11-06 19:52:59 UTC
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.
Comment 30 Cosimo Cecchi 2012-11-06 21:58:59 UTC
I've seen this very recently on my machine - I'll try to reproduce again.
Comment 31 Fred Muller 2013-01-30 06:44:23 UTC
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?
Comment 32 Joel Griffiths 2013-02-20 20:26:49 UTC
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.
Comment 33 Florian Müllner 2013-02-20 21:00:16 UTC
(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.
Comment 34 Florian Müllner 2013-02-20 21:00:39 UTC
I meant 3.6.3.
Comment 35 Giovanni Campagna 2013-03-03 13:03:30 UTC
*** Bug 695048 has been marked as a duplicate of this bug. ***
Comment 36 André Klapper 2013-08-31 13:11:29 UTC
(In reply to comment #34)
> I meant 3.6.3.

So is this fixed nowadays? (Symptoms in bug 662757 also sound related.)
Comment 37 Fred Muller 2013-08-31 15:30:19 UTC
Not on F19 with gnome-shell-3.8.4-2.fc19.i686 running, I haven't seen it.
Comment 38 Bastien Nocera 2014-11-09 17:28:12 UTC
Let's consider this fixed, as there haven't been any new cases for a year and a half.