Description of problem: After Gnome locks the desktop, I can not resume properly after entering my password. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Wait until screen is locked (after some time) 2. Wait until the screen is turned off 3. Press a key 4. Enter password 5. Get the locked icon in upper left corder icon 6. I can see the app switching (alt+tab) but the screen is locked and I can not do anything Actual results: I can not resume work Expected results: I should see the full desktop and running apps Additional info: - Harddisk is encrypted (though i don't see a problem there) - The only thing that actually works is pressing the power button which forces it to go to suspend (though resume doesn't work).
I am experiencing this as well. Mouse moves. My name is in upper left corner and Universal access, Volume and Network show up on the upper right. The screen background remains grey (the gdm default). Ctrl-Alt-F2 etc will not work. The screen turns back with no console appearing to allow me to log in. At this point I am able to ssh in from my phone and kill Xorg or execute init 3 followed by init 5. This will resolve the problem until it locks again. I'm not sure what info to provide to assist here. I don't know if it is a gdm problem? I also use a laptop with the XFCE spin that does not have this problem.
Created attachment 661581 [details] Picture taken when the problem occurs As you can see it's not unlocked.
Created attachment 661582 [details] Picture taken when the problem occurs This shows that alt+tab works. Please note that the huge number of evolution windows is due to me hitting enter multiple times.
I can confirm the behavior in the above two screenshots as well.
I'm wondering if this is an X bug, not GNOME at all. Can you try with 'nomodeset' kernel parameter? That should force use of the vesa driver, it'll be pretty slow, but does the bug happen then?
Setting nomodeset has no effect. The bug still persists. I noticed I am getting the following: gdm-simple-slave[2303]: WARNING: Failed to give slave programs access to the display. Trying to proceed. I'm not sure of the significance.
The funny thing is it doesn't happen all the time. It only happens 1 in 2 or 3 times. Also, if it helps, I'm running FC18 on a laptop.
I have seen the same issue with Gnome on 3.6.2 on FC 18 and it seems to be related to inotify. When I can't unlock the screen I see log messages like: gdm-password][5587]: AccountsService-WARNING: Failed to connect to the ConsoleKit seat object: No space left on device I've upped max user watches in /etc/sysctl.conf fs.inotify.max_user_watches=100000 and that has resolved the issue for me.
With the latest version of Gnome I have no further problems.
I'm also facing this issue in F18, * I can't access the desktop even after unlocking it (entered password, nothing happened). but still it shows locked icon on the top bar & grey background. * I can't see the windows/apps, but 'alt+tab' shows the opened windows (it means, able to unlock the screen). * Then I clicked login as other user which showed the login screen (not unlock screen) in VT3, at that point I'm able to access virtual terminal (vt) (alt+f2/f4). killed the gnome-session, but that didn't helped me. * As of now, rebooting is the only option, but I lost all my opened windows and sessions. This is severe bug, please increase the priority and severity to 'HIGH'. If anyone found any workaround to get out of this hell, please update here. Team, Consider it as data loss & fix it immediately.
I'm also seeing the same behaviour as Sri Ram -- not every time, but it's happened twice out of half-a-dozen unlocks since I installed Fedora. It's a clean install of F18 (my first!), with updates applied. Here: http://forums.fedoraforum.org/showthread.php?t=286705 someone suggested that the following might be useful: [axa@enyo ~]$ rpm -q gdm gnome-session gnome-shell gdm-3.6.2-5.fc18.x86_64 gnome-session-3.6.2-3.fc18.x86_64 gnome-shell-3.6.2-6.fc18.x86_64 Please let me know if I can provide any more information -- I'm really hoping this can be fixed quickly.
I found a workaround to get rid of this lock screen issue. After your screen got struck, do the following steps to restore your session. Steps : 1) Use 'Ctrl + Alt + L' to lock your screen. 2) Then drag it up ('Esc' won't work) and go to the password screen. 3) Click 'Log in as another user' and it'll get you to the actual login page. 4) Then press 'Ctrl + Alt + F3' to enter into virtual console. 5) In virtual console, login as root or any sudo user. 6) Get the process ID of 'gnome-shell' process in any of these methods : Method 1 : $ ps aux | grep gnome-shell sriram 1354 0.0 0.1 77196 12176 ? Ssl 09:08 0:00 /usr/bin/gnome-shell sriram 14677 0.0 0.0 4800 812 pts/3 S+ 12:51 0:00 grep --color=auto gnome-shell Method 2 : $ pidof gnome-shell 1354 7) Kill the process using 'SIGKILL' which automatically restarts the gnome-shell. $ kill -9 1354 8) Log out from root user by pressing 'Ctrl + D'. 8) Then press 'Ctrl + Alt + F1', it will take you to the lost 'gnome-shell' screen (without any password screen) which has all your running applications/windows. That's it!....
I can confirm this bug. I have an office full of irritated users encountering it (intermittently) on fedora 18. All desktops are dual-head. Notably, the screen actually does unlock eventually. It seems to take about 2.5 minutes. I can't see that anything is going on during this time, it's just stalled. [bill@cmp100 ~]$ rpm -q gdm gnome-session gnome-shell gdm-3.6.2-5.fc18.x86_64 gnome-session-3.6.2-3.fc18.x86_64 gnome-shell-3.6.2-6.fc18.x86_64 I see messages like this in /var/log/messages which seem to be correspond but may be unrelated: Feb 13 08:29:24 cmp103 dbus[512]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.0" (uid=0 pid=505 comm="/usr/lib/systemd/systemd-logind ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.604" (uid=1000 pid=3402 comm="gnome-session ")
A me too, with a workaround. increasing /proc/sys/fs/inotify/max_user_watches helps $cat /etc/sysctl.d/inotify.conf fs.inotify.max_user_watches=100000
I've not seen this for several months now -- wondering if it might have been fixed as a side-effect of another change?
Yes, it seems that this bug was fixed by some other patch. Anyway, whoever facing this bug, please update your system ('yum update') to fix it. Can we close this issue?
(In reply to William Guelker from comment #13) I got this on F19 today. Dual screen, as well. The screen unlocks after 60-90, apx. Tried deactivating all extensions, but got it again when returning from lunch. Nothing in the logs that stands out. App switching does not work. Switching to a VT and HUP:ing gnome-shell does, however. Due to this, I don't think the bug that I (and William Guelker?) experience is the same as originally reported. # rpm -q gdm gnome-session gnome-shell gdm-3.8.4-2.fc19.x86_64 gnome-session-3.8.4-1.fc19.x86_64 gnome-shell-3.8.4-2.fc19.x86_64
(In reply to Carl-Johan Schenström from comment #17) If it occurs again, try to lock (CTRL+ALT+L) and unlock the screen. I faced similiar issues, i.e gnome-shell hangs sometime when unlocking. So, Locking it again worked for me.
(In reply to Sri Ram from comment #18) > I faced similiar issues, i.e gnome-shell hangs sometime when unlocking. So, > Locking it again worked for me. Doesn't work here, I'm afraid.
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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.