Red Hat Bugzilla – Full Text Bug Listing
|Summary:||New lock screen sometimes fails to unlock|
|Product:||[Fedora] Fedora||Reporter:||Tim Waugh <twaugh>|
|Component:||gnome-shell||Assignee:||Owen Taylor <otaylor>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||18||CC:||alevy, cwawak, dtardon, fmuellner, john.ellson, jon.dufresne, marianne, maxamillion, naipaul_ojar, otaylor, rbu, samkraju, walters|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-02-05 07:25:28 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Tim Waugh 2012-10-03 04:32:23 EDT
Description of problem: Every so often I find that the lock screen will fail to unlock. I can get to the password screen, and type in my password, but clicking the Unlock button simply makes that button go insensitive. The only further possibility for interacting with the lock screen is by clicking the Cancel button (or pressing Escape on the keyboard). Version-Release number of selected component (if applicable): gnome-shell-3.6.0-1.fc18.x86_64 How reproducible: Occasional. Steps to Reproduce: 1.Seems to happen most often when I am in the middle of typing something, the Typing Break (drwright) screen kicks in, and I happen to press Enter. This triggers the 'Lock Screen' button.
Comment 1 John Ellson 2012-10-03 10:34:34 EDT
I've seen screen lock not accept my passwd too, on two fc18 x86_64 systems. Doesn't always happen. Haven't found a way to reproduce (Break key doesn't lock here ???) Does screen locking rely on /var/run/utmp to find who is logged in? If so, this might be related to #862776 (/usr/bin/who returns no results)
Comment 2 Alon Levy 2012-10-17 06:38:12 EDT
I've seen this too on a F18 x86_64. Just chiming in to get notifications for this bug. Alon
Comment 3 Tim Waugh 2012-10-17 07:35:30 EDT
Another symptom I've seen is that the login widgets disappear leaving the gray screen and the top bar, and then nothing happens. The screen is still not unlocked, but now all I can do is change the volume using the top-right widget.
Comment 4 Tim Waugh 2012-11-05 07:35:21 EST
This is still happening, and it's *extremely* annoying. What's the plan for fixing it?
Comment 5 Robert Buchholz 2012-11-22 10:52:49 EST
I am seeing the effect from comment 3 as well. For me, it is reproducible when the "Hamster" shell extension from gnome.org is enabled and I have at least clicked "No activity" once during the session. Is this bug possibly related to #855523?
Comment 6 Naipaul Ojar 2013-02-19 11:08:28 EST
I have seen this issue about 4 times, the last one 5 min ago. I can still access a console login and in a process list I see abrt had a crash with a negative XXXX. I thought that the message would have been saved in /var/log/messages, but I have searched for the message unsuccessfully. I will capture it and log the error here.
Comment 7 Naipaul Ojar 2013-02-20 18:12:47 EST
I believe this failure of the screen lock to be removed is actually a more generic issue Gnome Shell lockup. I had the graphical Gnome shell freeze up on my a few minutes ago and I was able to recover for the first time. This time I was using Gnome Shell and while the mouse moves around all systems seems to freeze, even my music stopped. The graphical display also freezes - which is one of he reasons why I choose to display the seconds on my desktop clock. 1. I went to a console login and I found my tell-tale symptom for F18: Strange Processes referred by abrt. root 910 1 0 11:25 ? 00:00:00 /usr/sbin/abrtd -d -s root 914 1 0 11:25 ? 00:00:00 /usr/bin/abrt-watch-log -F BUG corruption stack overflow protection fault WARNING: at nable to handle ouble fault: RTNL: assertion failed eek! page_mapcount(page) went negative! adness at NETDEV WATCHDOG ysctl table check failed INFO: possible recursive locking detected : nobody cared IRQ handler type mismatch /var/log/messages -- /usr/bin/abrt-dump-oops -xD root 927 1 0 11:25 ? 00:00:00 /usr/bin/abrt-watch-log -F Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD. 2. I sent the HUP signal to PID 914. 3. I also sent the HUP signal to gnome-shell and gnome-session - kill -9 will cause them to die and restart a new process, killing all active sessions. 4. Ctl-Alt-F1 - switch back to graphical X-Windows To mu surprise my Gnome Shell graphical came back to life and seems responsive. I am completing this a report in this revived session. I can also restart my music player.
Comment 8 Naipaul Ojar 2013-03-04 18:57:02 EST
I have upgraded to kernel 3.8.1 and to gnome-shell 22.214.171.124 and I am still seeing the issue. These are the results that I have found today. I am not sure if this is the same bug, but the freezing of Gnome Shell can occur at any time, not just when trying to unlock the screen. root 917 1 0 17:36 ? 00:00:00 /usr/sbin/abrtd -d -s root 920 1 0 17:36 ? 00:00:00 /usr/bin/abrt-watch-log -F BUG corruption stack overflow protection fault WARNING: at nable to handle ouble fault: RTNL: assertion failed eek! page_mapcount(page) went negative! adness at NETDEV WATCHDOG ysctl table check failed INFO: possible recursive locking detected : nobody cared IRQ handler type mismatch /var/log/messages -- /usr/bin/abrt-dump-oops -xD root 930 1 0 17:36 ? 00:00:00 /usr/bin/abrt-watch-log -F Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD nojar 2421 2054 0 17:36 ? 00:00:00 abrt-applet
Comment 9 Fedora End Of Life 2013-12-21 04:01:15 EST
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Comment 10 Fedora End Of Life 2014-02-05 07:25:37 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.