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

Even worse is that this ‘suspend’ shuts down my media server along with all other background tasks that normally run 24x7, such as boinc.

I agree that many may want to conserve energy, but those who run their desktop as a server as well should not be impacted without notice nor ways to alter that.

I have a system used as a Server (but running Workstation) sitting next to the network switch in the utility room, and Fedora Workstation in a old iMac in an outbuilding office. After installing F37 the
server dropped off the network overnight. I created a “drop-in” in `/etc/sleep.conf.d/.conf" to disallow the 4 “AllowX=yes” settings:

AllowSuspend=no
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no

My network monitoring software checks for internet connectivity and the server has been 100% outside one widespread power outage event.

For the office system, I often use ssh from a laptop, so have to do wake-on-lan when ssh doesn’t connect.

1 Like

My system does not have that /etc/sleep.conf.d/ directory nor can I easily find what would (should?) have created it.

# dnf provides /etc/sleep.conf.d
Last metadata expiration check: 3:07:02 ago on Sun 28 May 2023 06:22:06 AM CDT.
Error: No matches found. If searching for a file, try specifying the full path or using a wildcard prefix ("*/") at the beginning.

This particular system is F38 and has been regularly upgraded from F26. My laptop also does not show that directory with F37.

/etc/systemd/sleep.conf

You create it yourself when needed. See man sleep.conf.d. It is similar to a lot of other configuration files where you can create a directory for plugin files, and which will be protected from beeing modified by a software upgrade.

1 Like

I’m not certain of the relevance here, but I noticed recently (today) that if I don’t login when I first turn my Fedora WS , it suspends and I have to press the power button to bring up the system. This is prior to login mind you so it is with the BIOS I beleive, but I had made no changes, and this didn’t happen until after updating Fedora. This system is a PC, not a laptop, though it does have wireless which apparently seems to make Fedora treat it like a mobile device. I actually had to uninstall the power management that Fedora chose to use by default and install tuned to get Fedora to behave and not try to blank my screen or set non-performance mode (heck it wasn’t even an option). My point is it really P’d me off that someone arbitrarily decided that on upgrading my system, that it needed these changes.

When sitting at the login screen the OS is already active and services are running. Thus bios has nothing to do with the system suspending at that situation. The OS seems to be what causes the suspend, since bios does not perform suspends.

There is no detection of or different behavior for mobile devices here. I think this is the right thing to do — desktop PCs are even more likely to be left idling, possibly for days at a time, and are likely to draw a lot more power since that’s less likely to be a design concern.

Behavior changes do happen on upgrades. As I said in another thread, in retrospect this clearly should have been in the release notes. As it is, we’ve documented it here, in Common Issues (which is at least linked from notes.)

On this I am going to have to disagree. I use my PC daily, and turn it on in the AM, then off usually just prior to rest time. During the day it is running, sometimes unattended, and often performing some task or another for me. So making a change to my system, arbitrarily does affect my usage in a negative way. To me this also goes against the grain of why I use Linux in the first place, to have determined control over the behaviour of my device. While release notes are a nice thing to have and often quite informative with Fedora, it doesn’t qualify as justification IMO.

2 Likes

Stephen, You are exactly right. That was my point about Windows 11. I use Linux because I get to decide how my systems are used, not some unaccountable set of developers.

I think the excuse of ‘energy certification’ is a little suspect. I’ve never seen a certification for only a software component of a system that also contains hardware. The certifications always apply to the combination. So, a user option to allow their system to be killed at some preselected (by the user) times is fine. It is NOT OK to have these choices made by the devs unless they can absolutely guarantee there will be no ill effects.

In this case it should have been obvious that killing power to a system could be disruptive. Is there a dev mailing list where the users of the system can help educate these developers?

Dale Tyler

This seems unnecessary hostile. You don’t have to “suspect” or talk about “excuses”. You can just talk to us. (Without hyperbole about “educating”, please?)

We want to provide an OS which can be used “out-of-the-box” by hardware vendors, with no bespoke modifications. This is what we do with Lenovo, for example, and are hoping to also do with several other vendors.

As I’ve said, I agree in retrospect we should have advertised the change more clearly, and I think the login screen configuration should be more available. And, we did make a change, based on feedback, so that Fedora Server is not impacted.

Everyone here is should be able to take the steps we’ve documented to prevent suspending on systems, where you want that behavior. What is the further outcome you’re looking for, here?

What will make more sense is to roll back the automatic changes and let the user decide. I.e., leave the options as was before (off) and present a pop-up (or something else) and the user can decide what to do. On my case, nothing worked, and the only solution was to disable GDM and activate KDM. It was very disruptive, not only when migrating to FC38, but also after applying changes (dnf update). We users should not be punished on the same way that MS is doing with Win 10/1 users. I am using Linux to avoid all those nightmares caused by Windows.

The fact that those power changes don’t take in account remote access to the computer (SSH etc) and simply shutdowns it, it is obviously a bad implemenattion.

It was great that the change did not impact users of the server version.

The downside of the change is that it did not consider the major impact it would have on users of Workstation (or any of the other spins) that use the machine as both a server and a workstation, so it drastically impacted the server services that were running – including any VMs that may have been running as servers for the user. The VMs are killed just as if there was a sudden power off, which is never good for any OS.

I should not need to have a separate dedicated server, drawing more power, in order to keep my services running uninterrupted while my workstation gets forced into suspend because of a change in the OS. After all, one workstation that is also acting as a server will draw less power than 2 different systems, 1 workstation and 1 server.

Yes you said it was a lack of communication, but that does not sit well for many. Let us know what is in the works or being planned, and how the affects can be mitigated before we are slapped in the face after-the-fact and scrambling to find out why and how to recover.

After all, Fedora is supposed to be a community based project, and users deserve to be heard when major changes are considered (before they take effect).

1 Like

I guess this is the point, the variety of the hardware. As a lot of drivers nowadays are included in the kernel we need to keep an eye more on the kernel change-log than on the Fedora Change Sets.

A few changes have been reported just searching for keyword like s0ix in
6.1 & 6.2

#  https://cdn.kernel.org/pub/linux/kernel/v6.x/
# ChangeLog-6.1 & ChangeLog-6.2

$ cat * |grep --color=auto  -i "s0ix" -B 4 -A 4

     "Last set of fixes for final, scattered bunch of fixes, two amdgpu, one
      vmwgfx, and some misc others.
    
      amdgpu:
       - S0ix fix
       - DCN 3.2 array out of bounds fix
    
      shmem:
       - Fixes to shmem-helper error paths
--
    
    amd-drm-fixes-6.1-2022-12-07:
    
    amdgpu:
    - S0ix fix
    - DCN 3.2 array out of bounds fix
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    From: Alex Deucher <alexander.deucher@amd.com>
--
Date:   Thu Dec 1 11:17:31 2022 +0800

    drm/amdgpu/sdma_v4_0: turn off SDMA ring buffer in the s2idle suspend
    
    In the SDMA s0ix save process requires to turn off SDMA ring buffer for
    avoiding the SDMA in-flight request, otherwise will suffer from SDMA page
    fault which causes by page request from in-flight SDMA ring accessing at
    SDMA restore phase.
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2248
    Cc: stable@vger.kernel.org # 6.0,5.15+
    Fixes: f8f4e2a51834 ("drm/amdgpu: skipping SDMA hw_init and hw_fini for S0ix.")
    Signed-off-by: Prike Liang <Prike.Liang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Tested-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
--
    - add -wifitrace argument for tracing all the way to wifi reconnect
    - include more data in ftrace to mark the end of kernel resume
    - add async_synchronize_full to the list of funcs to chart
    - add thermal zone info to the log data
    - include a check for s0ix support (s2idle is the default mem_sleep)
    - if s2idle does not support s0ix, remove the SYS%LPI turbostat var
    - fix -dev crash when kprobe caller is just an address (not a symbol)
    - fix the cpuexec data in -proc to display in resume
    
    sleepgraph.8:
--
    energy when suspended to idle.  If that flag is unset, doing so is
    generally risky.
    
    Accordingly, add a comment to explain the ACPI_FADT_LOW_POWER_S0 check
    in amdgpu_acpi_is_s0ix_active(), the purpose of which is otherwise
    somewhat unclear.
    
    Link: https://uefi.org/specs/ACPI/6.4/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model.html#fixed-acpi-description-table-fadt # [1]
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
--

    ata: ahci: Add Tiger Lake UP{3,4} AHCI controller
    
    Mark the Tiger Lake UP{3,4} AHCI controller as "low_power". This enables
    S0ix to work out of the box. Otherwise this isn't working unless the
    user manually sets /sys/class/scsi_host/*/link_power_management_policy.
    
    Intel lists a total of 4 SATA controller IDs in [1] for those mobile
    PCHs. This commit just adds the "AHCI" variant since I only tested
--

    Merge tag 'acpi-6.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
    
    Pull ACPI fixes from Rafael Wysocki:
     "These are new ACPI IRQ override quirks, low-power S0 idle (S0ix)
      support adjustments and ACPI backlight handling fixes, mostly for
      platforms using AMD chips.
    
      Specifics:
--
         (Mario Limonciello).
    
       - Fix Apple GMUX backlight detection (Hans de Goede).
    
       - Add a low-power S0 idle (S0ix) handling quirk for HP Elitebook 865
         and stop using AMD-specific low-power S0 idle code path for systems
         with Rembrandt chips and newer (Mario Limonciello)"
    
    * tag 'acpi-6.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
--
       - Reserved VMID handling fixes
       - FRU EEPROM fix
       - BO validation fixes
       - Avoid large variable on the stack
       - S0ix fixes
       - SMU 13.x fixes
       - VCN fix
       - Add missing fence reference
    
--
      drm/amdgpu: enable VCN DPG for GC IP v11.0.4
      drm/amdgpu: skip mes self test after s0i3 resume for MES IP v11.0
      drm/amd/pm: correct the fan speed retrieving in PWM for some SMU13 asics
      drm/amd/pm: bump SMU13.0.0 driver_if header to version 0x34
      drm/amdgpu: skip MES for S0ix as well since it's part of GFX
      drm/amd/pm: avoid large variable on kernel stack
      drm/amdkfd: Fix double release compute pasid
      drm/amdkfd: Fix kfd_process_device_init_vm error handling
      drm/amd/pm: update SMU13.0.0 reported maximum shader clock
--
    amd-drm-fixes-6.2-2022-12-21:
    
    amdgpu:
    - Avoid large variable on the stack
    - S0ix fixes
    - SMU 13.x fixes
    - VCN fix
    - Add missing fence reference
    
--
    drm/amdgpu: skip mes self test after s0i3 resume for MES IP v11.0
    
    MES is part of gfxoff and MES suspend and resume are skipped for S0i3.
    But the mes_self_test call path is still in the amdgpu_device_ip_late_init.
    it's should also be skipped for s0ix as no hardware re-initialization
    happened.
    
    Besides, mes_self_test will free the BO that triggers a lot of warning
    messages while in the suspend state.
--
    [   81.689707]  ret_from_fork+0x22/0x30
    [   81.690118]  </TASK>
    [   81.690380] ---[ end trace 0000000000000000 ]---
    
    v2: make the comment clean and use adev->in_s0ix instead of
    adev->suspend
    
    Signed-off-by: Tim Huang <tim.huang@amd.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
--
commit afa6646b1c5d3affd541f76bd7476e4b835a9174
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Dec 16 11:42:20 2022 -0500

    drm/amdgpu: skip MES for S0ix as well since it's part of GFX
    
    It's also part of gfxoff.
    
    Cc: stable@vger.kernel.org # 6.0, 6.1
--
    - VCN RAS fixes
    - APU fix for passthrough
    - PSR fixes
    - GFX preemption support for gfx9
    - SDMA fix for S0ix
    
    amdkfd:
    - Enable KFD support for GC 11.0.4
    - Misc cleanups
--
Date:   Thu Dec 1 11:17:31 2022 +0800

    drm/amdgpu/sdma_v4_0: turn off SDMA ring buffer in the s2idle suspend
    
    In the SDMA s0ix save process requires to turn off SDMA ring buffer for
    avoiding the SDMA in-flight request, otherwise will suffer from SDMA page
    fault which causes by page request from in-flight SDMA ring accessing at
    SDMA restore phase.
    
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2248
    Cc: stable@vger.kernel.org # 6.0,5.15+
    Fixes: f8f4e2a51834 ("drm/amdgpu: skipping SDMA hw_init and hw_fini for S0ix.")
    Signed-off-by: Prike Liang <Prike.Liang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Tested-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
--
    e1000e: Add e1000e trace module
    
    Add tracepoints to the driver via a new file e1000e_trace.h and some new
    trace calls added in interesting places in the driver. Add some tracing
    for s0ix flows to help in a debug of shared resources with the CSME
    firmware. The idea here is that tracepoints have such low performance cost
    when disabled that we can leave these in the upstream driver.
    
    Performance not affected, and this can be very useful for debugging and
--
    Above essentially unlocks SX+streaming scenarios i.e.: power transitions
    with an ongoing stream.
    
    As some streams are allowed to run in low power state, support is
    provided for S0iX state. The handlers check ACPI capabilities and the
    number of active low-power paths before deciding between SX and S0iX
    flows.
    
    The last portion of the patchset is addition of power/clock gating
    overrides. There is no single set of registers that ensures AudioDSP
--
Date:   Thu Oct 27 14:47:00 2022 +0200

    ASoC: Intel: avs: Standby power-state support
    
    Introduce avs_suspend_standby() and avs_resume_standby() to support S0IX
    streaming. The AudioDSP is not shutdown during such scenario and the PCI
    device is armed for possible wake operation through an audio event.
    
    As capability for a stream to be active during low power S0 is based off
--
Date:   Thu Oct 27 14:46:59 2022 +0200

    ASoC: Intel: avs: Count low power streams
    
    Streaming in S0iX differs from SX scenarios. Store the number of
    so-called low-power streams to be able to differentiate between the two.
    
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://lore.kernel.org/r/20221027124702.1761002-7-cezary.rojewski@intel.com
--
    ASoC: Intel: Skylake: simplify S3 resume flows
    
    Commit cce6c149eba3a ("ASoC: Intel: Skylake: add link management")
    added a perfectly logical/symmetrical link handling for
    'suspend_active' aka S0ix
    
    However that commit also added a less obvious part, where during S3
    resume the code will "turn off the links which are off before suspend"
    as well as stop the cmd_io which is not started.

So, the changes not came totally out of nowhere. We could also see them when they got reported.
We just not had a solution how to turn them off independent of the DE. Now we do have a workaround:

# Creating a drop-in to deactivate Suspend and Hybernation

sudo mkdir -p /etc/systemd/sleep.conf.d && sudo tee /etc/systemd/sleep.conf.d/sus-hib-off.conf << "EOF"
[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no
EOF
1 Like

In my experience (one Fedora System on an old iMac over a few weeks since upgrading to F38), the system stays up while I’m actively using ssh, and can be brought back up using wake-on-lan (when I need to use ssh from my laptop). I live in a home designed to be “net-zero” using solar panels, so we monitor power usage. One key signal is the “always-on” baseline usage. We are in the bottom 24% of comparable houses with 2 people, at less than 600 watts. The “target” for comparable houses is 650 watts. A couple systems sleeping when not actively being used is a significant reduction in “always-on”.

1 Like

Well, specifically, I think this should have gone through the Changes Process. There would have been wider community discussion[1]. Based on that feedback, perhaps we would have decided to add something to keep the behavior change from occurring on upgrades. The Change would have included something for the release notes, and possibly some wider communication plan.

We try to make sure all significant changes like this go through that process. But, again, in a volunteer-driven community, sometimes things slip through. I’m sorry that happened.


  1. currently, on the devel mailing list, but on this site for future releases ↩︎

should that not be /etc/systemd/sleep.conf.d or make the changes directly into /etc/systemd/sleep.conf?

Yes /etc//etc/systemd/.

1 Like

Hi George,

SSH connections do not prevent system kill on my F38 system. While I commend you for your interest in reducing your electricty use, some of us are also focused on using computers for the tasks that they were able to accomplish in the past. F38 took us back a step or three in terms of usability. Worse, the Devs seem to have no idea how systems are used and make incorrect decisions as a result.

Plus, this whole notion of ‘certification’ as an excuse seems to be bogus. I’d like to hear the details of exactly which certification was issued as a result of this highly intrusive and disruptive change.

Dale

I would like to spend two words on this thread.

I think that we should keep in mind at least two kind of users: power users like the majority of people that are participating in this thread and the rest of the world :sweat_smile:
I think that introducing this behavior (ok, It should have been publicized a little more) is perfectly fine for the rest of the world.

For instance in this case, users like that are power users. It is supposed that they know what to do, or at least they are capable to find the answers in order to change the defaults that someone else decided to arbitrarily [1] put in place.

During the pre-release phase of Fedora Linux 38 I incurred in this issue as well. I didn’t understand why my PC was going to sleep even if I didn’t change anything, suspecting that it was a bug. I asked that in some Fedora Chat channel, I don’t remember, and turned out not to be a bug. And now that I’m aware of this behavior, I have no problem. On my laptop I leaved it as is. On my desktop I disabled automatic suspend. Done.


  1. please note the italic typeface; in fact, at first instance, I always think there are good intentions behind the choices, like in this case ↩︎

3 Likes