Description of problem: Every time when I try to unlock the screen, I write a password, press unlock and it freezes. Since the lock screen is apparently part of the gnome-shell I have to kill it which kills the whole session which is quite ..... unfortunate. Version-Release number of selected component (if applicable): gnome-shell-3.6.1-3.fc18.x86_64 How reproducible: 100% Steps to Reproduce: 1. ctrl-alt-del to lock the screen 2. try to unlock 3. Actual results: the lock screen freezes and nothing happens (I tried to wait even a few minutes) Expected results: Unlocked screen Additional info: - first experienced this bug about a month ago a since then I used xlock as an alternative, today I tried it again and find out that it's still broken
I installed the GA release on F18 on 3 computers. On 2 of them, the lock screen will not unlock sometimes after long periods of inactivity. The 3rd computer so far has not failed to unlock, but it's only been 3 days since I installed F18. Today I locked one machine at 9:45am and came back at 12:30pm. The screensaver was black when I returned, moving the mouse brought back the display, but the time on the display indicated 10:40 with the large Chevron arrows. The mouse was operational, but the screen would not unlock no matter which keys I tried. I could go into a virtual console (ctl-alt-f2) and login, where I was able to kill off the gnome session which did free up the GUI screen but terminated all of my running programs. Both computers are patched to current with the same levels of kernel, gnome, etc. [root@linux1 ~]# uname -a Linux linux1.localdomain 3.7.2-201.fc18.x86_64 #1 SMP Fri Jan 11 22:16:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [root@linux1 ~]# rpm -q gnome-shell gnome-shell-3.6.2-6.fc18.x86_64
This is happening for me, too. It seems to only happen when I'm running X-Com through Wine, though. After I slide up and unlock, the screen remains grey and I can alt-tab between running applications and actually use them. I saved my game by holding alt-tab and navigating that way. Alt-F2 works also, and I ran gnome-session-quit to log out and was able to then log back in. Before hitting submit on this, I locked and was able to successfully unlock without the issue happening again.
(In reply to comment #2) > This is happening for me, too. It seems to only happen when I'm running > X-Com through Wine, though. After I slide up and unlock, the screen remains > grey and I can alt-tab between running applications and actually use them. > I saved my game by holding alt-tab and navigating that way. > > Alt-F2 works also, and I ran gnome-session-quit to log out and was able to > then log back in. Before hitting submit on this, I locked and was able to > successfully unlock without the issue happening again. Running the following: [moldvanm@sysl002t ~]$ rpm -qa | grep gnome-shell gnome-shell-extension-common-3.6.2-1.fc18.noarch gnome-shell-3.6.2-6.fc18.x86_64 gnome-shell-extension-user-theme-3.6.2-1.fc18.noarch I just found the gnome-screensaver-command program, which I will try with "--exit" next time the bug happens.
The lock problem has not reoccurred on any of my now 4 PC's using F18. I have been patching F18 very regularly, perhaps one of the patches fixed the problem. Current kernel is: Linux murraysj.isc-seo.upenn.edu 3.7.4-204.fc18.x86_64 #1 SMP Wed Jan 23 16:44:29 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Gnome is: [root@murraysj ~]# rpm -qa | grep gnome-shell gnome-shell-3.6.2-6.fc18.x86_64
I am havin the same issue. I am using F18 # rpm -qa | grep -i gnome-shell gnome-shell-extension-common-3.6.2-1.fc18.noarch gnome-shell-3.6.2-6.fc18.x86_64 gnome-shell-extension-user-theme-3.6.2-1.fc18.noarch This are the errors that were added to the gnome-shell session log in between the times where I had to use <alt> + <F2> +"r" to unlock my screen. /home/<userid>/.cache/gdm/session.log JS LOG: GNOME Shell started at Wed Feb 06 2013 11:01:21 GMT-0600 (CST) ** Message: applet now embedded in the notification area JS LOG: pushModal: invocation of begin_modal failed Window manager warning: Log level 8: meta_end_modal_for_plugin: assertion `compositor->modal_plugin == plugin' failed JS ERROR: !!! Exception in callback for signal: unlocked JS ERROR: !!! message = '"incorrect pop"' JS ERROR: !!! fileName = '"/usr/share/gnome-shell/js/ui/main.js"' JS ERROR: !!! lineNumber = '638' JS ERROR: !!! stack = '"popModal([object _private_St_Widget])@/usr/share/gnome-shell/js/ui/main.js:638 ()@/usr/share/gnome-shell/js/ui/screenShield.js:838 wrapper()@/usr/share/gjs-1.0/lang.js:204 ()@/usr/share/gnome-shell/js/ui/screenShield.js:808 wrapper()@/usr/share/gjs-1.0/lang.js:204 ([object Object])@/usr/share/gnome-shell/js/ui/screenShield.js:688 wrapper([object Object])@/usr/share/gjs-1.0/lang.js:204 _emit("unlocked")@/usr/share/gjs-1.0/signals.js:124 ([object Object])@/usr/share/gnome-shell/js/ui/unlockDialog.js:275 wrapper([object Object])@/usr/share/gjs-1.0/lang.js:204 _emit("verification-complete")@/usr/share/gjs-1.0/signals.js:124 ([object _private_Gdm_UserVerifierProxy],"gdm-password")@/usr/share/gnome-shell/js/gdm/util.js:328 wrapper([object _private_Gdm_UserVerifierProxy],"gdm-password")@/usr/share/gjs-1.0/lang.js:204 "' Window manager warning: Log level 8: meta_end_modal_for_plugin: assertion `compositor->modal_plugin == plugin' failed JS ERROR: !!! Exception in callback for signal: Unlock JS ERROR: !!! message = '"incorrect pop"' JS ERROR: !!! fileName = '"/usr/share/gnome-shell/js/ui/main.js"' JS ERROR: !!! lineNumber = '638' JS ERROR: !!! stack = '"popModal([object _private_St_Widget])@/usr/share/gnome-shell/js/ui/main.js:638 ()@/usr/share/gnome-shell/js/ui/screenShield.js:838 wrapper()@/usr/share/gjs-1.0/lang.js:204 ([object _private_Gio_DBusProxy],":1.1",[object Array])@/usr/share/gnome-shell/js/ui/screenShield.js:425 _emit("Unlock",":1.1",[object Array])@/usr/share/gjs-1.0/signals.js:124 _convertToNativeSignal([object _private_Gio_DBusProxy],":1.1","Unlock",[object _private_GLib_Variant])@/usr/share/gjs-1.0/overrides/Gio.js:126 "' Window manager warning: Log level 8: g_source_remove: assertion `tag > 0' failed gnome-session[1537]: WARNING: Detected that screensaver has left the bus ** Message: applet now removed from the notification area JS LOG: GNOME Shell started at Wed Feb 06 2013 13:15:26 GMT-0600 (CST) ** Message: applet now embedded in the notification area Failed to open VDPAU backend libvdpau_nouveau.so: cannot open shared object file: No such file or directory
This is a known upstream issue, see https://bugzilla.gnome.org/show_bug.cgi?id=689106. Once we get design OK on the attached patch, we should probably get a backport into 3.6.
gnome-shell-3.6.3-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/gnome-shell-3.6.3-1.fc18
gnome-shell-3.6.3-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/gnome-shell-3.6.3-2.fc18
gnome-shell-3.6.3-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
I just installed gnome-shell-3.6.3-2 this morning....and since then, this issue has *started* happening for me i.e. I didn't experience this issue before the update. To fix, I drop to a terminal (ctrl-alt-f2) and SIGHUP the gnome-shell process
I have the same issue and i am running gnome-shell-3.6.3-2. Here is my session.log http://paste.fedoraproject.org/3991/
This affects me as well, as of latest update from testing repo. Happens every time and I can't resume my session. Really annoying.
The problem has not reoccurred for me since late January on any of my computers (now four of them). I have not changed any hardware or firmware on any of them, all that has changed is the OS.
I'm having the same problem as comments 10, 11, and 12. This worked fine before. When the screen locks, I can flick up the lock screen and type my password. After some time (30 seconds maybe?) I get an "Authentication Error" despite having typed the correct password, and the screen remains locked. Similar to IanB, I have been recovering by terminating gnome-shell from a separate VC, then restarting it.
This continues to be a problem for me, and a big one that impacts my work. This doesn't happen all the time, but from time to time. And when it does, I can't even open a new tty anymore, because when I do, for some reason, instead of seeing letters on the screen, I see gibberish. Like instead of the letter a, there will be $ or something like that. That's probably a seperate bug, but it only means that I can no longer count on being able to get work done because of the screen locking. If there's any more information I can provide, please let me know.
Well, all had been great until today. I patched today and got a new kernel, 9 hours later the problem had resurfaced. Looks like the bug has been closed, perhaps it should be reopened. [murraysj@linux1 murraysj]$ uname -a Linux linux1.localdomain 3.9.5-201.fc18.x86_64 #1 SMP Tue Jun 11 19:40:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [murraysj@linux1 murraysj]$ last reboot reboot system boot 3.9.5-201.fc18.x Wed Jun 19 18:09 - 18:23 (00:13) reboot system boot 3.9.5-201.fc18.x Wed Jun 19 08:30 - 18:08 (09:37) reboot system boot 3.9.4-200.fc18.x Fri Jun 7 19:15 - 08:30 (11+13:14) reboot system boot 3.9.4-200.fc18.x Wed Jun 5 18:09 - 08:30 (13+14:20) reboot system boot 3.8.11-200.fc18. Mon May 6 18:42 - 18:09 (29+23:27) reboot system boot 3.8.8-202.fc18.x Mon Apr 22 20:41 - 18:41 (13+22:00) reboot system boot 3.8.5-201.fc18.x Thu Apr 4 18:08 - 20:40 (18+02:32) reboot system boot 3.7.9-201.fc18.x Sun Feb 24 12:31 - 18:07 (39+04:36) reboot system boot 3.7.6-201.fc18.x Fri Feb 8 22:55 - 12:30 (15+13:35) reboot system boot 3.7.4-204.fc18.x Sat Feb 2 17:44 - 22:55 (6+05:10) reboot system boot 3.7.2-204.fc18.x Mon Jan 21 11:36 - 17:44 (12+06:07) reboot system boot 3.7.2-201.fc18.x Sat Jan 19 00:14 - 11:35 (2+11:21) reboot system boot 3.7.2-201.fc18.x Fri Jan 18 12:47 - 00:12 (11:24) reboot system boot 3.7.2-201.fc18.x Thu Jan 17 22:37 - 12:47 (14:09) reboot system boot 3.7.2-201.fc18.x Thu Jan 17 22:31 - 22:37 (00:05) reboot system boot 3.7.2-201.fc18.x Thu Jan 17 22:22 - 22:30 (00:08) reboot system boot 3.7.2-201.fc18.x Thu Jan 17 21:05 - 22:22 (01:16) reboot system boot 3.7.2-201.fc18.x Thu Jan 17 19:16 - 21:04 (01:48) reboot system boot 3.7.2-201.fc18.x Thu Jan 17 19:09 - 19:15 (00:06) reboot system boot 3.7.2-201.fc18.x Thu Jan 17 19:07 - 19:09 (00:01) reboot system boot 3.6.10-4.fc18.x8 Thu Jan 17 18:15 - 19:06 (00:51) wtmp begins Thu Jan 17 18:15:41 2013 [murraysj@linux1 murraysj]$
The problem resurfaced for me as well after an upgrade to kernel 3.9.6 The only workaround I've found is switching from gdm to lightdm. Ironically I had just started using gdm again for a few days and had not experienced problem until this morning after the kernel update. I wonder if there's anything in the kernel update causing this? Anyway, I'm back to lightdm until this is solved, which may not happen now the bug has been closed I guess.
I am also affected. In Fedora 19, if the Screen Lock is ON, there is no way to unlock it. Only workaround is to disable screen lock
I have this problem since I have installed Fedora 18 in Jan-2013. I can't reproduce it. It used to happen very often after the screen inactivity auto lock. Now rarely happens, but it did happen today. After I unlocked the screen and changed focus from one window to another, the alt+tab popup seemed unable to steal the mouse focus and the alt+tab popup remained open indefinitely. I've pressed ctrl+alt+del and waited for the auto power off. gnome-shell-3.6.3.1-2.fc18.x86_64 gnome-shell-extension-user-theme-3.6.2-1.fc18.noarch gnome-shell-extension-common-3.6.2-1.fc18.noarch
I'm currently experiencing this on Fedora 20. It happened after a recent 'yum update'. The only other thing that is different is that I am currently running rsnapshot. After it finishes, I am hoping that a restart will fix the issue. It would be useful to know: 1) How to work around this issue. 2) How to disable the screenlock from the commandline
I had this problem back in Fedora 18 but not since -- see my Comment 14. The problem, for me, turned out to be an insufficient number of inotify max_user_watches. I was using Dropbox (containing a significantly large number of files) and CrashPlan for backup (managing tens of thousands of files). So as a first debugging step, try increasing the number of user watches to something really large, like a binary million. First, cat /proc/sys/fs/inotify/max_user_watches to see what the current number is, just for comparison's sake. then: echo 1048576 | sudo tee /proc/sys/fs/inotify/max_user_watches This won't persist past a reboot. If it works, make it permanent by adding the line "fs.inotify.max_user_watches=1048576" to the end of /etc/sysctl.conf (or within a new .conf file in /etc/sysctl.d, but be aware of .conf file precedence rules if you do it this way). I don't know if there's much of a downside to increasing this number, except for (obviously) an increase in memory usage. But it's a very small increase. If that solves your problem, great. This is a really poor failure mode for the Gnome Shell and could stand to be improved.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora 'version' of '20'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 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 this bug is closed as described in the policy above. 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 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.