Talk: GNOME suspends after 15 minutes of user inactivity, even on AC power

It does seem odd that something affecting so many users could be missed in beta testing. I don’t know if there is tracking of beta tester coverage, but this should encourage more users to participate. I do my own tests using removable media before upgrading and was happy to see improvements to linux power management – too often I get called away for some “simple” issue that takes hours. Wake-on-lan has been useful.

Very well said Jeff.

@computersavvy Is there a reason you don’t want to share the problem and workaround you found, which might help some people here?

I asked before but saw no answer. What setting does Fedora Server use to suppress or not enable this behaviour? I hope it is a single global setting.

What files actually changed in F38 to implement the new policy?

The commit for Fedora’s server override is here:
https://src.fedoraproject.org/rpms/fedora-release/c/6f94a4dbbc29d2725f60d0f844530a63f4122999?branch=rawhide

The commit for the gnome-settings change is here:
https://src.fedoraproject.org/rpms/gnome-settings-daemon/c/c8f9665aca0617a921ec308a0f1d2741d92dc41d?branch=rawhide

The workstation pagure issue: https://pagure.io/fedora-workstation/issue/360

If you wanted to apply the override you would need to create that file in /usr/share/glib-2.0/schemas/ and then run sudo glib_compile_schemas /usr/share/glib-2.0/schemas/

If a user had been previously set up you may also need to run gsettings reset org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout

4 Likes

See my posts

and

and the one above

Additionally I used the gnome settings to disable auto suspend from within gnome, but the one that seems to have fixed it (semi-)permanently was masking the 4 targets

I do have a problem in that if I leave a chrome window open while the screen is locked it sometimes causes the system to crash. When I close chrome before walking away from the keyboard the system does not crash. I don’t think this has anything to do with the subject of suspend though.

1 Like

The proper way to ask for revert of the autosuspend is to contact Workstation WG. I think they also watch workstation-wg tag in Project Discussion . Link to this topic, to showcase that there are more people than just you who are not happy.

The proper way to file a bug if the recommended solution isn’t working is to file a bug against gnome-settings-daemon.

This is a discussion topic for the issue documentation, the developers aren’t reading it.

1 Like

Well, some of us are. But, yeah.

Can someone tell me how “energy-consumption certifications” is more important than having users?

Come on — that’s not a question in good faith.

But, I’ll answer a different one! How are energy certifications important for Linux to get new users?

We’ve known from user research — and just from questions on Ask Fedora — that getting a system installed with all the hardware working is the biggest barrier to wider adoption of Fedora Linux — and Linux desktop systems in general.

The best way around that is to get more vendors providing systems with Fedora Linux preinstalled. The only way to do that is for those vendors to meet government requirements. Including energy use.

Actually, the question poses an interesting tension between the manufacturers who seem to want/need energy certification to pre-install Fedora or some other OS and the need for existing users to upgrade without significant or breaking changes.

One way to resolve this conflict is to not change behavior for upgrades, but allow the ‘new’ behavior to be the default for new installations, with detailed instructions on how to restore the time tested functionality for those who like the ‘old’ way better. I hope the Fedora Management is listening.

This change broke many systems, especially those that were upgraded remotely and then required an expensive trip to a remote location to bring them back into operation after the system powered off unexpectedly. Adding to that was the problem that the menu items that are supposed to control power savings shutoffs were broken and required a complicated set of steps to restore what has always been the expected functionality.

I hope that the Fedora Developers have learned a lesson from this and will try to avoid disabling users’ systems when they are upgraded. Some people care about energy savings and some people use their workstation as a 24x7 server and never want the power to be removed by some energy saving protocol.

Also, note that the solution proposed is not 100% complete, despite the claim “This topic has a solution already” and some people report their system is still losing power after running updates.

Another breaking change that the developers added in Fedora 38 was the forced application of updates and a mandatory restart with way for a user to stop it. While I understand that some people like Windows 11 style of update management, some of us want 24x7 availablility without forced reboots killing our systems.

Matthew, I appreciate what you do, but you should understand that sometimes mistakes are made and there were at least two whoppers commited by the Fedora Developers in Fedora 38. I hope Fedora 39 works better.

This is also a kind of not respecting the users privacy, changing settings to force an update. Unfortunately I also realized that change. Normally I not let gnome update. I like to do this with dnf to check what happens.

About the solution I did set, I took it away again. Sorry about that, I just realize it now how ugly it is, whitewashing and not acknowledging the other’s concerns.

Having worked in a large enterprise and lost fights to get linux on desktops, energy consumption is a big deal with upper management and facilities managers. New buildings are designed around per seat energy needs and energy demand schedules. Linux has advantages over Windows on issues of security, but until linux can meet large enterprise requirements for power management it can’t make inroads in a market segments that is top of mind for vendors. Many linux users take advantage of 2nd hand systems that were originally purchased by large enterprises.

Side note: I once tried to purchase systems identical to the ones used by a large enterprise for our university-based collaborators and was told they could only be purchased in quantities over 1000.

1 Like

George,

I agree that for PC vendors to pre-install Linux on systems they sell, those systems must pass government energy certifications and meet other regulations.

Howover, the need for maximum power saving on some systems should not destroy the operation of existing users’ systems. That’s a false choice and an unforced error that the Fedora Devs made when they added this feature. They recognized that the Server Edition of Fedora could not have systems randomly being powered off after some period of inactivity on the screen. They failed to recognize that many Fedora Workstation users have the same need - no random killing of the power based on the last time the mouse was moved.

The Fedora Devs ‘made the perfect the enemy of the greater good’. Hopefully they will have learned from this error and will correct the errors in the development process for Fedora 39 and beyond. They need to fix the broken settings dialog associated with power. Perhaps even have a single switch that say “Never power off for any reason unless explicitly commanded to do so by the user”. That’s what I want.

What are the reasons for using Fedora Workstation, instead of Fedora Server, as server with remote access through SSH?

Why automatic suspend after inactivity in GUI in workstation variant is such big deal for you? Why are you not using server variant for server purposes?

I can answer generically for many who only have one workstation.

For many years and for most distributions a workstation has been able to run server apps and remain online 24/7 so those apps can be accessed remotely.

My workstation runs the plexmediaserver so I can access a media library from anywhere in my home 24/7.

The sudden change to suspend after 15 minutes idle makes that server unavailable for remote access after 15 minutes without keyboard or mouse activity and breaks the normal home usage of the system. The suspension even interrupts a streaming video from the media server.

Similar actions are seen with many other “server” apps.

The fact that the aim is to reduce power usage is great. Breaking normal usage for those who have only one machine and use it as both a workstation and home server is not.

Additionally, the server release does not support gui management by default and thus many of the home apps that rely on a gui for management cannot be easily used on the server release.

Several obstacles were exposed by this sudden change.

For me, it forced that I disable the 15 minute time-out.

Are you certain that 100% of all users have multiple machines they can dedicate to the role of workstation and server? Or do the majority only have one system? If they only have one system then there is no power savings by shutting one down since the one being used as a server needs to remain available.

Further to what Jeff V said:

I’ve never had the call a computer a workstation or a server. I’ve never had to decide either/or.

Most of my notebooks are workstations most of the time. The change would probably be beneficial for them. I would much prefer for it to be an opt-in change.

Most of my other computers are servers AND clients, at least some of the time. The change breaks them.

Recovering from this change is quite awkward and hard to find. Some more accessible settings would be useful. And a system-wide one too.

I can’t think of any Unix/Linux machine I have owned or used in the past 25 years that was not running sshd, either by default or because it was enabled.

I view the Fedora Server edition as a package intended for headless operation, with little or no need for graphics or direct physically connected interaction with a keyboard/mouse. So, the Server Edition is unsuitable and would have to be extensively hacked to make it useful.

You are really asking the wrong question. Instead, ask why the Fedora developers decided to cripple a vast collection of users’ systems in pursuit of energy savings certificate? They had to know that many, many Fedora users would be damaged by this declension, yet the proceeded and did not catch it during design or code reviews. Hopefully, the Fedora developers have learned from this mistake and will consult with a wider population of users before making ‘breaking’ changes to an important piece of software.

That’s a better question to ask the Fedora Developers.

You are really asking the wrong question. Instead, ask why the Fedora developers decided to cripple a vast collection of users’ systems in pursuit of energy savings certificate?

Having more users thanks to having Fedora preinstalled on devices is probably more important than keeping default configuration of desktop OS compatible with not-so-desktop-like niche use case.

If you use your computer as server, you should install server variant which provides default configuration optimized for server usage. You can easily install desktop environment and login screen in Fedora server with dnf.

The only issue I see here is that GNOME does not take SSH active sessions into account when deciding about whether user currently is idle or active. GNOME already is able to handle SSH session when when trying to power off computer (there is warning in dialog) so there is technical way to handle it also in auto suspend code.

However, still. If you use your compuser as server, use server OS and just add desktop environment on top of that. You are doing it wrong so you are having unwanted result.

In context of changing default configuration on upgrade I think there is nothing wrong with that on Fedora side. Fedora is not LTS, it’s bleeding edge OS. Each upgrade (like 37 to 38) does not have to be 100% without manual interventions, especially with server-like usage (it should be for desktop user experience, however).

Before I retired my group was moved into building that was stripped down to the support structure and then rebuilt to energy efficient standards with a budget of 300 watts per cubicle. Windows systems were configured to sleep when idle. We also had a couple RHEL and many macOS systems. To stay within the energy budget, with the linux systems running 7x24, required suspending systems when idle. Wake-on-lan was used to initiate ssh and VNC sessions on the macOS systems.

WOL lets me open ssh sessions on my sleeping F38 workstation (located in an outbuilding) via ssh.