I got surprised by this today when upgrading my home automation server from Fedora 37 to 39, then, 15 minutes after upgrading when everything seemed to be working, I found it suspended.
Normally this would be no real issue, I should just be able to resume, disable suspending, and continue. Unfortunately, this computer was an Intel NUC5i5RYH, which are known to brick themselves upon suspending, and this is what happened. To make things worse, the suggested fixes for this are not functioning, the computer appears to be dead.
I acknowledge that this is an unusual edge case that is likely to be very rare, nevertheless, I had a working computer that was still quite useful, and now I have a paperweight.
It really might be worth revisiting the idea of setting these values for upgraded systems.
Sorry to hear about your expensive paperweight.
Yes, a lot of us were caught by surprise with the change to “suspend after 15 minnutes idle”. Most were able to recover but it seems the only spin that was not forced into that was fedora server.
You are not really an edge case since many were running servers within VMs, or media servers, or doing remote management of machines many miles away, and many other situations. The only part I see that was an edge case for you was the particular hardware you were using.
I got a bit surprised that you just joined up one day ago. If you do have delicate hardware I would have done this before and also asking what difficulties you might could get into it. I do think while working with opensource software, this should be a must.
But now the problem exists lets try to fix it.
I guess we talked a lot about this. If the community needs a Gnome version without the bells and whistles of power-saving, then the community has to be worried about it. A own SIG for it has been the closest what has been proposed. A close cooperation with the official Workstation team would might help to avoid such things happen in the future.
Fedora is know to push ahead and not pulling the handbrake to stay there where it is.
Is there any clear solution to that gdm suspends the system even when remote user is logged in via ssh? This seems really crazy to me and it still happens on latest updates.
In my home, designed for netzero, I appreciate the attention that went into reducing Fedora Workstation power requirements. Only 25% of comparable homes have lower “always on” loads, and most of my “always on” load is network and intercom.
Is the remote user on the same local network? For my home network, ssh to a Fedora workstation connected to the wired network, wake-on-lan allows me to start an ssh session from a laptop using wifi.
We currently don’t have any policy on when to close Talk topics related to Common Issues , but at least for this one, I think it makes sense to still keep it open for some time. This change got introduced in F38 (but people could’ve upgraded F37->F39 and meet it in F39 for the first time), and F39 is still a supported release. When people deal with problems related to the linked common issue, it’s easiest to have a centralized topic for them here.
In Fedora 43, while setting up the new suspend time, users might encounter the following issue:
(process:6842): dconf-WARNING **: 03:19:29.245: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code4: Failed to create file “/var/lib/gdm/.config/dconf/user.48R6E3”: No such file or directory
It’s archived now, even though it’s still valid - the idea was that we document it only when it hits most users as a big change between releases. But the fact that people are still looking at it suggests we should re-think the process. We can’t maintain various “gnome tweaks”, but it would be nice to have a community section for these guides. People don’t seem to enjoy contributing to Fedora Quick Docs :: Fedora Docs , unfortunately. Which reminds me we already talked about this before:
This solution does not work for Workstation 43, as sort of reported in the by the mail thread creator (although things later started magically working for him).
Here’s the output for the settings on my end, after running the install command for both .config and .cache for gdm:
Sadly, after 15 minutes, my machine, an AC powered mini-PC, still suspends. I’m just letting you know since the guide might give the impression that by creating the gdm folders actually solves the problem in Fedora Workstation 43, but it doesn’t.
Also, if you could point me in the right direction for support regarding this issue, I’d very much appreciate it.
@rafaeldamasceno Your values seem OK. Does your system suspend when you boot into GDM and no user is logged in? Because if you have some user logged in, you need to configure suspend for each user as well, as the guide says.
After resuming, look into system journal, whether it hints what triggered the suspend.
Also, check if you don’t have some custom logind.conf override in your system.
Yes, it’s only booting into GDM. The machine is used as a home server, I only install Workstation because having a DE ends up being useful a lot of times. This is why it’s critical to be able to configure GDM sleep settings. The only user is configured to not suspend (it’s my current workaround, logging in to the user to have the machine not suspend itself).
I hadn’t changed anything, but I took a look anyway and haven’t found any logind.conf.d or logind.conf override.
Here’s the entire journal from the moment the sleep is triggered by logind until the device is sleeping. You can also clearly see the gnome-shell entry
Jan 08 10:44:08 upsilon gnome-shell[1580]: Screen lock is locked down, not locking
to suggest that I never really logged in.
Jan 08 10:44:08 upsilon kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Jan 08 10:44:08 upsilon kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Jan 08 10:44:08 upsilon systemd-logind[722]: The system will suspend now!
Jan 08 10:44:08 upsilon ModemManager[810]: <msg> [sleep-monitor-systemd] system is about to suspend
Jan 08 10:44:08 upsilon NetworkManager[915]: <info> [1767869048.7370] manager: sleep: sleep requested (sleeping: no enabled: yes)
Jan 08 10:44:08 upsilon ModemManager[810]: <msg> [sleep-monitor-systemd] ready to sleep; dropping inhibitor
Jan 08 10:44:08 upsilon NetworkManager[915]: <info> [1767869048.7375] device (wlo1): state change: unavailable -> unmanaged (reason 'unmanaged-nm-disabled', managed-type: 'full')
Jan 08 10:44:08 upsilon NetworkManager[915]: <info> [1767869048.7385] device (wlo1): set-hw-addr: reset MAC address to 64:49:7D:F4:51:DC (unmanage)
Jan 08 10:44:08 upsilon NetworkManager[915]: <info> [1767869048.7398] manager: NetworkManager state is now DISABLED (ASLEEP)
Jan 08 10:44:08 upsilon NetworkManager[915]: <info> [1767869048.7400] device (enp1s0): state change: activated -> deactivating (reason 'sleeping', managed-type: 'full')
Jan 08 10:44:08 upsilon gnome-shell[1580]: Screen lock is locked down, not locking
Jan 08 10:44:08 upsilon systemd[1]: Starting NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service...
Jan 08 10:44:08 upsilon systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service.
Jan 08 10:44:08 upsilon audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 08 10:44:08 upsilon NetworkManager[915]: <info> [1767869048.7852] device (enp1s0): state change: deactivating -> disconnected (reason 'sleeping', managed-type: 'full')
Jan 08 10:44:08 upsilon avahi-daemon[696]: Withdrawing address record for fe80::69ec:d2e1:a41b:b802 on enp1s0.
Jan 08 10:44:08 upsilon avahi-daemon[696]: Leaving mDNS multicast group on interface enp1s0.IPv6 with address fe80::69ec:d2e1:a41b:b802.
Jan 08 10:44:08 upsilon NetworkManager[915]: <info> [1767869048.7884] dhcp4 (enp1s0): canceled DHCP transaction
Jan 08 10:44:08 upsilon avahi-daemon[696]: Interface enp1s0.IPv6 no longer relevant for mDNS.
Jan 08 10:44:08 upsilon NetworkManager[915]: <info> [1767869048.7890] dhcp4 (enp1s0): activation: beginning transaction (timeout in 45 seconds)
Jan 08 10:44:08 upsilon NetworkManager[915]: <info> [1767869048.7894] dhcp4 (enp1s0): state changed no lease
Jan 08 10:44:08 upsilon avahi-daemon[696]: Withdrawing address record for 192.168.3.14 on enp1s0.
Jan 08 10:44:08 upsilon avahi-daemon[696]: Leaving mDNS multicast group on interface enp1s0.IPv4 with address 192.168.3.14.
Jan 08 10:44:08 upsilon avahi-daemon[696]: Interface enp1s0.IPv4 no longer relevant for mDNS.
Jan 08 10:44:08 upsilon systemd-resolved[654]: enp1s0: Bus client reset search domain list.
Jan 08 10:44:08 upsilon NetworkManager[915]: <info> [1767869048.8068] device (enp1s0): state change: disconnected -> unmanaged (reason 'unmanaged-nm-disabled', managed-type: 'full')
Jan 08 10:44:08 upsilon kernel: r8169 0000:01:00.0 enp1s0: Link is Down
Jan 08 10:44:08 upsilon audit[813]: NETFILTER_CFG table=firewalld:83 family=1 entries=46 op=nft_unregister_rule pid=813 subj=system_u:system_r:firewalld_t:s0 comm="firewalld"
Jan 08 10:44:08 upsilon systemd-resolved[654]: enp1s0: Bus client set default route setting: no
Jan 08 10:44:08 upsilon systemd-resolved[654]: enp1s0: Bus client reset DNS server list.
Jan 08 10:44:08 upsilon systemd[1]: Reached target sleep.target - Sleep.
Jan 08 10:44:08 upsilon systemd[1]: Starting systemd-suspend.service - System Suspend...
Jan 08 10:44:08 upsilon chronyd[702]: Source 162.159.200.1 offline
Jan 08 10:44:08 upsilon chronyd[702]: Source 193.136.152.71 offline
Jan 08 10:44:08 upsilon chronyd[702]: Source 185.11.166.59 offline
Jan 08 10:44:08 upsilon chronyd[702]: Can't synchronise: no selectable sources (4 unreachable sources)
Jan 08 10:44:08 upsilon chronyd[702]: Source 91.209.16.78 offline
Jan 08 10:44:08 upsilon systemd[1]: user@60578.service: Unit now frozen-by-parent.
Jan 08 10:44:08 upsilon systemd[1]: session-c1.scope: Unit now frozen-by-parent.
Jan 08 10:44:08 upsilon systemd[1]: user-60578.slice: Unit now frozen-by-parent.
Jan 08 10:44:08 upsilon systemd[1]: session-2.scope: Unit now frozen-by-parent.
Jan 08 10:44:08 upsilon systemd[1]: user@1000.service: Unit now frozen-by-parent.
Jan 08 10:44:08 upsilon systemd[1]: user.slice: Unit now frozen.
Jan 08 10:44:08 upsilon systemd[1]: user-1000.slice: Unit now frozen-by-parent.
Jan 08 10:44:08 upsilon systemd-sleep[6768]: Successfully froze unit 'user.slice'.
Jan 08 10:44:08 upsilon systemd[1]: session-4.scope: Unit now frozen-by-parent.
Jan 08 10:44:08 upsilon systemd-sleep[6768]: Performing sleep operation 'suspend'...
Jan 08 10:44:08 upsilon kernel: PM: suspend entry (deep)
Jan 08 10:44:08 upsilon kernel: Filesystems sync: 0.035 seconds
PS: I think you tagged someone that isn’t me in your post.
Interesting. There are some people who have the same problem as you, even though the guide works just fine for many others (me and Petr included). It would be great if we could figure out the reason. Not sure how to debug this, though. Maybe you could create logind.conf.d and override the systemd config (probably IdleAction and IdleActionSec, maybe some more, I just quickly scanned the man page), whether that changes anything or not.
to no avail, the same exact thing has happened, sleep after 15 minutes. Which is somewhat good/expected, since the default IdleAction is supposed to be ignore anyway. I also read all the stuff there and don’t seem to find any other setting that is useful. Maybe setting SleepOperation to empty?.. I’ll try in the meantime, but assume it didn’t work if I don’t update.
About the guide: with Workstation 42, it worked perfectly. Just setting the org.gnome.settings-daemon.plugins.power options is enough. With a clean install of Workstation 43, doing the same thing fails because of the missing folders, and even after creating them and having no more errors changing the settings, the behavior doesn’t change. I suppose the removal of the GDM home folder has more than meets the eye to have it be fixed just by recreating the folder.
As for why it works for you, I’m not sure! Did you test it running Workstation 43? Was it an upgrade to 43 from 42 and some other needed stuff was kept or also a clean install? Are running it in a VM or in real hardware?
Fedora is know to push ahead and not pulling the handbrake to stay there where it is.