GNOME suspends after 15 minutes of user inactivity…
The statement is not completely true. I was kicked out of my SSH session while I was actively working. There was no 15 minute timeout.
I haven’t changed power settings on my desktop system and regularly use ssh from a laptop. I have not encountered any active session getting closed, but idle sessions do time out. I use wake-on-lan to get a new ssh session. Journalctl may have some details. I don’t know if there are quirks with some hardware in power management. I have seen some strange jumps in time stamps in logs, so maybe there are time glitches.
SSH sessions are not counted as user activity. I’ve updated the issue description.
Does You can use 0 to disable the delay completely mean it disables autosuspend completely, or does it mean it will suspend without any delay?
Hehe. Meaning the system would suspend immediately once you stop moving the mouse? 
I’ve clarified the sentence, it disables autosuspend, of course.
…after applying updates today, this problem is back.
now i had to create a script to run at system startup to ensure that those changes are always in place,.
this is insanity
I applied the suggested changes, and others, and my system continues to goes down …
System enter in sleep mode every 15 minutes
May 16 16:29:45 HG000009 systemd-logind[2616]: The system will suspend now!
....
May 16 16:29:46 HG000009 systemd[1]: Reached target sleep.target - Sleep.
May 16 16:29:46 HG000009 systemd[1]: Starting systemd-suspend.service - System Suspend...
May 16 16:29:46 HG000009 systemd-sleep[122532]: Entering sleep state 'suspend'...
My setup
$ sudo -u gdm dbus-run-session gsettings list-recursively org.gnome.settings-daemon.plugins.power | grep sleep
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 0
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'nothing'
@afberendsen Just to confirm, the suspend happens while the system is in GDM (and not logged in)? After what time? And you’re saying that those gsettings values reset to defaults, if you reboot your system?
I have a console session (not logged in) and a remote session (logged in with my account).
I will restart the system again and leave only the console authentication open (not logged in).
I assume SSH session will not change anything.
I will post an update in 20 minutes .
SSH session…system down again… 
… 15 minutes…I am starting to consider that there is something else also dealing with power management that is not gdm alone.
what is really annoying is the fact that there are remote connections to the machine and it still goes into sleep mode.
[afberendsen@HG000009 ~]$ sudo tail -f /var/log/messages|grep -v audit|grep -v journal
May 16 17:22:30 HG000009 steam.desktop[9356]: LogonFailure No Connection
May 16 17:23:38 HG000009 steam.desktop[9356]: LogonFailure No Connection
May 16 17:24:44 HG000009 steam.desktop[9356]: LogonFailure No Connection
May 16 17:25:10 HG000009 systemd[1]: Starting pmlogger_check.service - Check pmlogger instances are running...
May 16 17:25:10 HG000009 systemd[1]: Starting pmlogger_farm_check.service - Check and migrate non-primary pmlogger farm instances...
May 16 17:25:10 HG000009 systemd[1]: Started pmlogger_check.service - Check pmlogger instances are running.
May 16 17:25:10 HG000009 systemd[1]: Started pmlogger_farm_check.service - Check and migrate non-primary pmlogger farm instances.
May 16 17:25:10 HG000009 systemd[1]: pmlogger_farm_check.service: Deactivated successfully.
May 16 17:25:10 HG000009 systemd[1]: pmlogger_check.service: Deactivated successfully.
May 16 17:25:11 HG000009 wpa_supplicant[3326]: wlp13s0: CTRL-EVENT-SCAN-FAILED ret=-22
May 16 17:25:52 HG000009 steam.desktop[9356]: LogonFailure No Connection
May 16 17:27:03 HG000009 steam.desktop[9356]: LogonFailure No Connection
May 16 17:27:10 HG000009 systemd[1]: packagekit.service: Deactivated successfully.
May 16 17:27:10 HG000009 systemd[1]: packagekit.service: Consumed 7.800s CPU time.
May 16 17:28:00 HG000009 systemd[1]: Starting pmie_check.service - Check PMIE instances are running...
May 16 17:28:00 HG000009 systemd[1]: Started pmie_check.service - Check PMIE instances are running.
May 16 17:28:00 HG000009 systemd[1]: pmie_check.service: Deactivated successfully.
May 16 17:28:09 HG000009 steam.desktop[9356]: LogonFailure No Connection
May 16 17:28:10 HG000009 systemd[1]: Starting pmie_farm_check.service - Check and migrate non-primary pmie farm instances...
May 16 17:28:10 HG000009 systemd[1]: Started pmie_farm_check.service - Check and migrate non-primary pmie farm instances.
May 16 17:28:10 HG000009 systemd[1]: pmie_farm_check.service: Deactivated successfully.
May 16 17:28:40 HG000009 systemd[1]: Starting systemd-tmpfiles-clean.service - Cleanup of Temporary Directories...
May 16 17:28:40 HG000009 systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully.
May 16 17:28:40 HG000009 systemd[1]: Finished systemd-tmpfiles-clean.service - Cleanup of Temporary Directories.
May 16 17:28:40 HG000009 systemd[1]: run-credentials-systemd\x2dtmpfiles\x2dclean.service.mount: Deactivated successfully.
May 16 17:29:19 HG000009 steam.desktop[9356]: LogonFailure No Connection
May 16 17:30:00 HG000009 systemd[1]: Starting sysstat-collect.service - system activity accounting tool...
May 16 17:30:00 HG000009 systemd[1]: sysstat-collect.service: Deactivated successfully.
Broadcast message from gdm@HG000009 on tty1 (Tue 2023-05-16 17:30:13 CEST):
The system will suspend now!
I left the system running only with the console GUI authentication screen, touching the arrows keys, and the sleep is not happening. … Now I have to figure out where is the sleep timeout set-up …
now i am on the real of desperation…chaging the set-up for the root account too
$ sudo -u root dbus-run-session gsettings list-recursively org.gnome.settings-daemon.plugins.power | grep sleep
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 900
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 900
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'suspend'
$ sudo -u root dbus-run-session gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
$ sudo -u root dbus-run-session gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 0
$ sudo -u root dbus-run-session gsettings list-recursively org.gnome.settings-daemon.plugins.power
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 0
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'suspend'
I will wait 30 more minutes, not touching the console keyboard, and let’s see what happens…and its down again…same 15 minutes timeout
darn it…my system was working so well until I had the idea to upgrade to Fedora 38…
just found this page: [GNOME] Disable automatic hibernation | The FreeBSD Forums. I will try the additional settings and let’s see what happens. … no changes … system entered in sleep mode again…
19:05:55 up 1:29, 2 users, load average: 0.59, 1.69, 1.68
Broadcast message from gdm@HG000009 on tty1 (Tue 2023-05-16 19:05:57 CEST):
The system will suspend now!
client_loop: send disconnect: Connection reset by peer
any clues @kparal ?
well…solution was to disable gdm and enable kdm…now my system is up and running w/o problems.
@afberendsen It seems that gdm ignores the gsettings that you configured. But I have no idea why. I guess the best approach here is to file a bug against gdm and let developers look into it.
Could this be a solution? Using hibernation and not suspend? Are you still on Gnome 43 ?
Since I am powering up the computer and just leaving it running, with all the configurations set-up to not ever enter into sleep mode, I don’t think this applies…or am I misreading the contents of the erticle?
Systemd also manages sleep settings: man 5 systemd-sleep.conf or Systemd Sleep Configuration. For my server (which gets checked periodically for internet connectivity) I created a file: /etc/systemd/sleep.conf.d/<hostname>.conf by copying sleep.conf and then editing it to remove the leading # and change yes to no for the 4 “#Allow” lines. My desktop uses the default settings.
I use wake-on-lan when I need to connect to it with ssh.
1 Like
Nice. But, since I swapped GDM for KDM, the problem is solved. Evidently is something with GDM, not the sleep service.
Yes, for your user case. And just to clarify, GDM is very strict integrated into the gnome-shell and the gnome desktop. It is made to use it together as a workstation.
Your user case, connecting over ssh is more the server approach. KDM ist just doing some tasks as starting a service on a other level, independent of the gnome ecosystem, independent of being a workstation.
As I see, the problem Is totally gnome related.
Problem
Since Fedora 38, systems with the GNOME desktop environment suspend after 15 minutes of user inactivity, even when plugged in to the AC outlet. This affects new installs and some upgraded systems (depending whether you touched that setting in the past).
This is due to an intentional change. To give it a better visibility, and because it might surprise many users and consider it a bug, it’s documented here.
Note: Remote sessions might not be considered when GNOME tracks user activity. Graphical remote sessions might count as user active, but that depends on the session server. An SSH session is not counted towards user activity.
Note: Fedora Server ships a configuration override, which defaults to not suspending on AC power by default. In all other Fedora editions, the described configuration change should apply, as long as you have GNOME environment running.
1 Like
We should do the same for other desktop environments, and will need to if vendors want to ship those preinstalled.
I probably have to correct my statement and say that the problem of @afberendsen had, was totally gnome based, and also the solution we do discuss here.
This has historically reasons. Display managers have been responsable/able to do power/saving changes. With KDM this still seams to be the case. GDM delegates the work apparently to the gnome shell while make the changes with gsettings alias in the underlying DB.
I would be grateful if your question, I could read between the lines 
, (how is it don then with other DE’s) would be discussed in a separate followup topic. The reading audience would probably be thankful for it.
1 Like
After GDM was disabled and KDM was enabled, everything is working as expected.
At the console, the “turn off screen after 15 minutes” works as expected.
The local GUI at the console is up and running, all the remote VNC sessions are working as expected and no more system suspend events.
@ vgaetera, this was my first action. I first tried with the gdm account with no good result. Then I also changed my own profile and the suspend problem still happened. Then, because I was very p* o*, I make those changes for all accounts in the sustem…still not working.
I have been using Fedora since FC1 and before that with the Redhat series.
This auto kill of a booted system when sitting at the login screen is one of the most ill advised decisions that the Fedora Devs have ever made.
This is NOT Windows 11. If I boot MY SYSTEM, I expect it to stay running. Add to this the random non-dismiss-able FORCED updates that kill work in progress and you have a very unfriendly and unexpected system behavior.
Please put a way to disable all of the automatic poweroff/automatic updates in the Settings panel and have them default to OFF. Or, make the setting of these options part of the installation process. There is no reason to surprise users with changes like this.
Imagine you are a new user of Fedora. You install the newest release, boot your system, start downloading updates and walk away to get coffee. When you come back, the screen is blank and the system is off. What went wrong? Why? So, they just decide Fedora is buggy and format the disk. This is an unforced error in user interface design.
By the way, the comment that systems ‘start up fast’ from suspend/hibernate is not always true and often damages whatever work was in-process.
I appreciate the passion. As discussed in the topic above, this needs to be the default in order to get energy-consumption certifications — and that makes sense to me, as idle devices doing nothing really add up. So, we can do our part.
GNOME suspends after 15 minutes of user inactivity, even on AC power describes how you can change this for systems where you want a different behavior. I do agree that we should have easier login screen / lock screen configuration — we’ll talk to GNOME upstream about how to best provide that.
Note that processes can request for suspend to be inhibited, and that should happen automatically when applying updates via GNOME Software. If that didn’t happen, that’s a bug.
Thanks for the reply, Matthew.
I appreciate the idea of trying to save power. We pay $0.83/kwH here in California. That said, this is a major change in usability that should be highlighted during installation. Maybe in the pop-up screens that show on first boot? Or, during the process that asks for timezone, etc.
Your contention that ‘idle devices doing nothing’ is a waste of power is reasonable, but if there is an ssh or other network traffic, then the system is not actually idle.
I always turn off all suspends because I have long running tasks that cannot be interrupted. The real surprise here was killing the power when sitting at the login screen. I know how to read logs so it was fairly simple to find out why the system died. What was not simple is learning that I have to issue an ‘gdm dbus’ command to restore normal behavior. That’s the unfriendly part of this change. It also appears that this gdm change is erased by updates. So, I’ll have to spend more time firuring out which package I will need to block updates from to preserve my change.
Do you have an idea about which package I should exclude from updates that overwrite my gdm change?
As to the upgrade stuff, the problem I had was that about 15 minutes after I logged in, a pop-up kept appearing demanding that I allow the system to be powered off to install updates. Despite clicking 'cancel, it appeared about ever 10-15 seconds. After 30 or so dismissals, it just killed power. This is NOT OK. It motivated me to kill packagekit and gnome-software to restore control of MY SYSTEM.
I have developed software for more than 40 years. If I or one of my team did anything like this, they would be given a lesson on proper user interface design.
Thanks,
Dale