Hide Forgot
Description of problem: When no one is using the computer for a while, the monitor goes to sleep after 10 minutes. Depending on how long one is away the computer wakes up normally or locks the user in some kind of jail. If this happens, the monitor goes on, everything is shown just as before leaving the machine earlier, one can move the mouse, but that's all. No interaction possible any more. By now, the only solution I have found for this is calling a console ( e.g. [ctrl]+[alt]+[f2] ) and execute "pkill gnome-shell". Version-Release number of selected component (if applicable): gnome-shell-3.0.2-1.fc15.x86_64 How reproducible: Go away from computer for some hours. Actual results: User is locked in "jail". Expected results: Normal wake up.
Dup of 705609
I experience the same problem. Some more info: When the machine comes back alive, all is good AS LONG AS I DO NOT HIT THE 'ACTIVITIES' TAB for the DOCK. Once I do that, I'm dead in the water. I can still pop windows back and forth, but that's all I can do. I cannot move/resize them and the windows no longer take input. All I seem to be able to do is reboot :-( I could temporarily bypass this problem if the 'System Preferences-->Screen' dialog would allow me to set sleep to 'never,' but the max the dialog supports is 1 hour. This means every time I leave the machine alone for an hour I must reboot.
More info: Bug 705609 states that this behavior might be connected to running rdesktop. Indeed, this seems to be the case. I have now been able to repeat the faulty behavior when rdesktop is running an gnome goes to sleep and wakes up in a jail/bad state. When rdesktop is not running, gnome wakes up working fine.
Hm... I don't have rdesktop running, it is not even installed?
Thanks for that feedback Tobias. I'll continue a bit more testing (shutting down rdesktop before I leave work in the evening and seeing if the thing comes back nicely the next morning). Either way I'll report here what I find.
OK, so that connection with rdesktop was mostly imaginative. I keep having the 'jail' problem, even when rdesktop is not running when the machine goes to sleep. I apologize for the confusion.
This problem is still not solved. I feel like I'm back in the Windows days of the 90s; have to reboot several times a day. I have narrowed matters a bit (at least I now know how to replicate this). How to make it go deepfreeze/jail? walk away from your machine for a few hours. When I come back, my screen is black and the mouse and keyboard are dead. The on/off button on my box, however, blinks happily. When I push it, the system comes back alive. All seems to work fine UNTIL... I touch the top of the screen with my mouse or the 'activities' tab in the left upper corner ---> deepfreeze/jail. After doing this, I can pop windows to the front, BUT THAT'S ALL I CAN do. All other window interaction is dead. No resizing, no keyboard input, no buttons on the displays in the windows; nothing. All I can do is reboot... once again.
I think I finally figured out the culprit (sort of). It's rdesktop after all!!! The deepfreeze/jailing ONLY occurs when I leave rdesktop running and walk away for a a few hours. If I think about closing rdesktop down before I walk away, I lose a few mountpoints to our Windows system, but Gnome wakes up just fine when I come back. Walk away from the machine for a few hours with rdesktop going (rdesktopping to a windows machine), and guaranteed (100% of at least 30/40 tries), gnome freezes up and I must reboot. Well, at least I now can avoid the freeze (although I sometimes forget to kill rdesktop before I leave my office). i hope this is useful information. RR
Rene, If you're still on fedora-15. There have been some updates, fedora 16, While we cannot rule out rdesktop as a potentially another actor in slowing down the screen updates. For Bug 705609 the primary culprit was was that in the design of gnome-3, the applet rendering was pushed into the screen update cycle. The wireless applet had some bug, which took it a long time to finish its task, and that froze the screen on wake for a long time. An upstream bug was filed, fixed and made its way to fc16. Its possible other applets can hang the screen update cycle in the same way. if pkill gnome-shell brings results, then definitely its a gnome-shell redering issue. Checking the ~/.xsession-errors may offer more clues Killing/resetting set applet is another. Interesting to know, when possible i'll try to see if rdesktoping and leaving causes said effect, and will report if I find out anything.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached 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 to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping