Fedora Account System
Red Hat Associate
Red Hat Customer
My computer now will attempt to suspend if no user is logged in locally. That obviously prevents login with ssh, but additionally this system does not actually support suspend (it is an old server, not a desktop system and does not even advertise suspend capability in ACPI tables), so once the system attempts to enter suspend there is no way to wake the system, it has to be powered off and powered on to allow login. This behavior is new after the update from 37 to 38. The power settings shown in the system settings do not have suspend enabled, but my understanding is that those settings apply only to the current user and do not affect the behavior once all local users are logged out. I did have a tmux session running, that did not affect the behavior, once all users were logged out of physical console the system suspended after several minutes. Reproducible: Always Steps to Reproduce: 1. Log out from local sessions 2. wait 3. Actual Results: Screen is turned off, keyboard handler no longer responds to pressing caps lock or num lock keys (indicating that not just the screen is turned off, the system is not responding to user input at all). System no longer allows ssh login at that point. Expected Results: System will not suspend unless explicitly enabled, especially on systems which do not support suspend. System settings tools will provide a way to enable or disable the behavior.
I am not sure yet how to verify that gdm is actually the software responsible, but I did verify that in runlevel3 the computer does not attempt to suspend (checked using systemctl isolate runlevel3.target).
I changed two computers from gdm to sddm for login management, and the problem no longer occurs, so I think that does point pretty conclusively to gdm, or at least some setting which comes along with gdm.
See also bug 2188828 and the work around in https://discussion.fedoraproject.org/t/gnome-suspends-after-15-minutes-of-user-inactivity-even-on-ac-power/79801 seems to work after a reboot.
Yes, would have been useful to put in the F38 release notes. Contents of "Notable changes for desktop users" " " Seems like a miss for the release notes.
(In reply to Chris Caudle from comment #4) > Yes, would have been useful to put in the F38 release notes. > Contents of "Notable changes for desktop users" > " " > > Seems like a miss for the release notes. Nah. DNF upgrade should not have change the sleep/suspend behaviour of the existing install.
A few points/suggestions/whatever: 0) I understand this change was made in order to get some sort of "Energy Star" rating or something, and that's why it can't just be reverted. That's understandable, but I can think of a few things that might be done to make it less disruptive while maintaining this new badge of honor. 1) Even though the setting that controls this is taking effect before logging in, and is not a part of the *user's* config, it should be accessible and settable from the gnome desktop settings app under "Power". Something this major should be discoverable in the UI, rather than requiring a google search followed by a cut-paste of an obscure command found in the middle of a forum discussion. 2) Such a major change in behavior should not happen automatically as the result of an OS version upgrade - if it must be made the default, it should only be the default for new installs. Think of the case of an unattended remote upgrade using dnf system-upgrade - the user would download the new packages, then run "dnf system-upgrade reboot" and forget about it while the packages are being upgraded; most likely they would try another login at a time after the upgrade has completed *and the 15 minute suspend timeout has passed*, and so the machine would already be suspended. "Damn! The upgrade failed and now my box in the closet in Nevada/Wyoming/Poughkeepsie/wherever is bricked!" :-(. (Seriously, I can envision this happening *a lot*, and people won't be happy about it). 3) During installs, maybe this setting can default to "suspend when idle", but there should be a very visible checkbox to disable it so that everybody is aware of this behavior and able to change it. 4) The definition of "idle" could certainly use some refinement. Note everyone who installs Fedora Workstation actually uses it as a desktop system. I install Workstation rather than Server because I do like to occasionally login to the desktop for certain things, but 95% of the time the video output isn't even connected to anything. 5) Although I haven't had a chance to experience it, some commenters on the fedora discussion forum have said that "dnf update" erases the "fix" to the suspend; I suppose this might happen when gdm itself is updated? Anyway, that definitely needs to be fixed (thinking about it - the fact that the setting is overridden during package upgrades means that an unattended upgrade of Fedora Workstation to F38+ is essentially impossible).
When my Fedora 38 Workstation system doesn't respond to ssh I use "wol" wake-on-lan, then ssh does work. This does require that ssh is being used from another system on the same LAN. It seems many Workstation users aren't aware of wol (other distros use different names).
The hack I've used to fix this, after the fact: For each user - log in as user on GNOME desktop - Settings: Power: Power Saving Options: Automatic Suspend: Off - log out For gdm: sudo -u gdm dbus-run-session gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type nothing For other Desktop Environments: ?? Unfortunately this setting is per-user. Is that a clean global version? I understand that the Fedora Server version does not have this porblem -- how is that configured?
> I understand that the Fedora Server version does not have this > porblem -- how is that configured? The package fedora-release-identity-server contains an override file that previously was part of the gnome-settings-daemon package. Namely: /usr/share/glib-2.0/schemas/org.gnome.settings-daemon.plugins.power.gschema.override Actually there has always been a way of overriding dconf settings for all users on the system. You should find that the file /etc/dconf/profile/user (part of dconf) contains among other things the string "system-db:site" which means you can put things in /etc/dconf/db/site.d and then do "sudo dconf update" to update the site settings. It would look like this unless I'm much mistaken: [org/gnome/settings-daemon/plugins/power] sleep-inactive-ac-timeout=0
@imc.ac.uk thanks! Philosophical question: why is powering off the whole machine a DE thing? Should it not be a system-wide policy, for all DEs, perhaps in the form of a systemd setting? Even within one DE, a per-user policy for this feels wrong to me -- it affects the whole computer, not just the console user. On the other hand, screen blanking does seem to naturally be a per-user setting -- it only affects the user at that screen. (My expectations were formed on UNIX before there were UNIX workstations.)
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. 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 'version' of '38'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 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 Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.