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):
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.
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)
I've seen this too on a F18 x86_64. Just chiming in to get notifications for this bug.
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.
This is still happening, and it's *extremely* annoying. What's the plan for fixing it?
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?
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.
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.
I have upgraded to kernel 3.8.1 and to gnome-shell 184.108.40.206 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
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.
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
Thank you for reporting this bug and we are sorry it could not be fixed.