The Summary says it all. When I startup my desktop machine (which thus is always on AC), and leave it at the gdm screen it will suspend after being left alone for 30 minutes. This is not good, since I only leave it powered on when I intend to access it remotely. I would like to suggest to change the default power policy to never suspend while on AC power. Another reason for this is that suspend simply does not work on this (very recent) desktop machine. And I can honestly say I've never seen a desktop machine where suspend worked with Linux, so suspending desktop machines by default seems like a bad idea.
This must be a joke?
Hi, (In reply to comment #1) > This must be a joke? This is not a constructive comment. In the future please stay constructive and productive at all times, thanks for helping to keep Fedora culture of being excellent to each other. Regards, Hans
Sorry, I am just a bit frustrated about the various changes in Fedora these days. Using the system has a classic scientific / developer workstation and server seems far away from Fedoras interest and focus. To actually turn off the computer I after just have started it is plain silly imho. Any way, I guess the people implementing such features and pushing them to all users have verified that this is something really needed and a clear majority of the users want such behaviour. And after all, switching to KDM is not exactly difficult. Sorry about the noise, will hopefully not happen again.
So ideally, I guess, we would inhibit suspend if 1) wake-on-lan isn't supported and 2) there are network servers running (or configured to activate on port access) Also, (as mentioned by Hans in the corresponding mail thread), network activity should reset any idle counters. Not sure how hard the above would be to implement, though.
(In reply to comment #3) > Any way, I guess the people implementing such features and pushing them to all > users have verified that this is something really needed and a clear majority > of the users want such behaviour. This was just a silly bug: https://bugzilla.gnome.org/show_bug.cgi?id=660395 I've fixed this upstream and will be included in 3.2.1 -- I can update the 3.2.0 package if you guys want, but 3.2.1 is RSN.
(In reply to comment #5) > This was just a silly bug: https://bugzilla.gnome.org/show_bug.cgi?id=660395 > > I've fixed this upstream and will be included in 3.2.1 -- I can update the > 3.2.0 package if you guys want, but 3.2.1 is RSN. Good to know, and thanks for fixing this!
Is this behavior captured in the initramfs in some way? I am seeing essentially this problem when I boot some machines with rc9 kernels, but not with rc8 kernels. (Including one that doesn't use X.) For all of these systems I have checked that org.gnome.settings-daemon.plugins.power sleep-inactive-ac is set to false.
*** Bug 745207 has been marked as a duplicate of this bug. ***
I'm also hitting this or something similar on a system that does have X (using LXDE) but boots into multi-user.target and doesn't have gnome-power-settings installed. I'm not sure if it's suspending after 30 minutes of idle (nothing helpful in the system logs after reboot) but the machine reboots itself after my remote session (using nx) has been idle for 30 minutes. This started happening recently and might have been when I upgraded to the rc9 kernel. I'm going to try going back to rc8 to see if the problem continues.
gnome-settings-daemon-3.2.0-3.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/gnome-settings-daemon-3.2.0-3.fc16
Package gnome-settings-daemon-3.2.0-3.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gnome-settings-daemon-3.2.0-3.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-14238 then log in and leave karma (feedback).
gnome-settings-daemon-3.2.0-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
It looks like the rc9 issue is really separate. I seem to be triggering it pretty regularly this morning, which I hope to capture the traceback and use to open a kernel bug.