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

Mate “Control Center” > “Power Management” > “On AC Power” > “Put computer to sleep when inactive for…”

My use case is similar. My Fedora Workstation lives in an outbuilding, but I often use ssh from a laptop. Fortunately, the workstation supports wake-on-lan (install “wol” for Fedora, other distros use other names).

It turns out the my issue was in power management. I was lead astray by the fact that ssh failed causing me to think the the network was suspended when, in fact, the entire system was suspended. You can see the entire thread here: [SOLVED] Networking closes when users not logged in...

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? :slight_smile: 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… :frowning: … 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 :wink: , (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.