Bug 862553 - New lock screen sometimes fails to unlock
New lock screen sometimes fails to unlock
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
18
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Owen Taylor
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-03 04:32 EDT by Tim Waugh
Modified: 2014-02-05 07:25 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-05 07:25:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
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 3.6.0.2 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.

Note You need to log in before you can comment on or make changes to this bug.