This is a GNOME restriction. It's entirely possible to trigger suspend from the command-line, and I don't have that restriction in KDE Plasma.

I'm not sure where to go for this for this to be fixed expeditiously, though.

Oh - I assumed it was a Fedora chosen default....darn

This is what I have in Fedora KDE from a fresh install:

Here's what I have for Fedora Workstation:

Changing the default in GNOME seems fine to me. I'm not sure which module is responsible though.

@mpearson So I guess what you're asking is that we turn on the "plugged in" suspend configuration?

We could probably adjust battery power to 10 minutes and plugged in to 15 minutes?

Another clarification, does this also apply to desktop/tower certifications?

Hi @ngompa

Yes - for the settings. That would be perfect.

This is for mobile only. For desktop it is more complicated and I have to get back to you - regular desktops (things like the M70t and M70s) need to be energy certified and will need that setting; the workstation desktops (P620/P920/etc) get a different set of rules and their own category and I don't think this applies.

I've cloned this for Fedora KDE as well: fedora-kde/SIG#308

Oh - I assumed it was a Fedora chosen default....darn

GNOME defaults to suspending after 20 minutes even when plugged in. Fedora overrides this to happen only when not plugged in; see #42. If we enable suspend when plugged in:

• It will break sshd and other forms of remote access.
• It will break multiseat.
• It will break anything that doesn't take a suspend inhibitor (e.g. your important compile job)
• GNOME suspend inhibitors were completely broken at the time of #42. But that has since been fixed.

It's just a bad default. But if we have manufacturers that ship Fedora by default and really need the default to be 20 minutes, then I suppose users who have a problem with the automatic suspend will just need to change the setting, which is not particularly difficult to do.

Thanks @catanzaro

If this comes up with the Gnome folk then 20 minutes is not ideal as going to sleep takes a small amount of time. We have had issues where they took the measurement exactly on 20 mins, before the system had actually gone to sleep, and it failed.

Having it set to just a bit less than 20 fixes this but having a timeout of 19.5 mins seems...odd - hence the suggestion of 15.

I've had questions internally why we're not the same as Windows with 10 mins. From an eco-perspective and saving energy I can see the value there...though I personally find 10 mins is too short. It's very subjective though :)

The GNOME default is 20 minutes specifically because the regulation that you're trying to comply with says 20 minutes, so if that doesn't actually work well in practice, I imagine changing the default to 15 minutes will not be controversial.

I've dropped our override in gnome-settings-daemon-44~beta-4.fc38 for starters so it will default to always suspend after 20 minutes now, but you will still have the problem of the system possibly not suspending until a few seconds after you need it to be already suspended. @aday are you OK with changing this from 20 minutes -> 15 minutes upstream? Alternatively, perhaps some code changes would suffice to change this setting to a "suspend right before 20 minutes" rather than a "suspend right after 20 minutes."

CC @hadess due to previous interest in this setting

Changing the default to 15 minutes is probably the most expedient way to solve this problem.

We have no way to know when the last user interaction was during boot, and the system itself will take time to start counting (it's GNOME counting inactivity, so it won't start counting until gdm or an auto-login session is started).

Would be great for this bug to be filed upstream along with a link to the relevant regulatory environmental standards.

Ideally we would have it so the system goes to sleep after 15 mins. For the certification they test the power values after a 'long idle' of 20 mins so the aim is to have the system in as low power levels as possible by this point. Windows suspends after 10 mins and Ubuntu after 15 mins.

Odd. I investigated this just out of curiosity, but found that Ubuntu 22.04 actually has the same defaults as Fedora: suspend after 20 minutes on battery power, and never while plugged in.

@hadess - ack; I'll look at doing an upstream bug with details (might take me some time to pull it all together - please nag me if I forget...busy time is just starting here so it's easy for things to get missed).

@catanzaro - it's likely Canonical only change it in their OEM preload images...I feel like I should know the answer to that but don't...which is a bit embarrassing

@hadess - ack; I'll look at doing an upstream bug with details (might take me some time to pull it all together - please nag me if I forget...busy time is just starting here so it's easy for things to get missed).

Oh don't worry about this. I'll prepare a merge request and reference the original change to 20 minutes and this ticket.

That said, I notice the gnome-settings-daemon maintainers have several important unhandled merge requests, so that doesn't fill me with confidence.

Oh and I'll include the link to the regulations from here

Thanks all - really appreciate all the help.

So - I think all the above puts us in good shape for this years platforms (assuming it will be in regular Fedora release by end of March/April?)

For the P1G5 - I think asking for permission, as a short term one off special case, for us to change the setting in the existing preload is the best solution (I think we can do that as a config change...though I'm guessing a little bit).
If there's any concerns with us doing that or recommendations on the best way to present that to the community and get thumbs up let me know :)

I think we need @mattdm to discuss that.

Upstream merge request, CC @garnacho for context.

So - I think all the above puts us in good shape for this years platforms (assuming it will be in regular Fedora release by end of March/April?)

Fedora 38 release is scheduled for April, but delays are common and it's not unlikely that it could wind up happening in May.

I'd rather not backport this change to Fedora 37 if you really need it there, although it's nicer to users to not change default settings during the release lifetime. But do your images actually include updates? Because if you ship Fedora 37 GA image without any updates, then there's no point in preparing an F37 update.

OK - i think we should be OK with F38. I need to go and check one set of schedules...but I think we'll be fine.

We try and ship with the GA image if dates align but usually we have an updated release image that the Fedora release team builds for us that has important fixes since the GA release.

Once we've got a working preload image we don't update it - we just don't have the resources to be able to do the test/energy certify/release process sadly. It's quite a lot of work :)

@catanzaro: It's pretty common for @mpearson to take update respins for deployments.

See releng#10886, releng#11147, and releng#11174 as examples of this.

OK, then I can do an F37 update if requested, but so far it sounds like Mark is OK with F38. The change landed upstream already (thanks Carlos!) so it should be in gnome-settings-daemon 44.rc and therefore should reach F38 shortly.

Thanks all!
The only Q I have open is if we can get permission to modify the current preload to change the settings for the P1G5. I'll follow up with @mattdm on that separately.
OK if I close this ticket or is it better to leave it open until things land?

I think we can close this now.

I hope, this is the right place for this.

I'm using Fedora 38. I installed it using the Beta 1.3 installer two days ago and installed all available updates. Although I complete disabled standby (the system is mostly used as a VM host using VirtualBox), the system goes to sleep after 15 minutes. I'm controlling the system via RDP (using xrdp) and even while I'm using the system in a RDP session, the system goes into standby.

I hope, this is the right place for this.

I'm using Fedora 38. I installed it using the Beta 1.3 installer two days ago and installed all available updates. Although I complete disabled standby (the system is mostly used as a VM host using VirtualBox), the system goes to sleep after 15 minutes. I'm controlling the system via RDP (using xrdp) and even while I'm using the system in a RDP session, the system goes into standby.

You probably should report this against xrdp.

The RDP server should use Inhibit Locks to prevent system suspension.
https://www.freedesktop.org/wiki/Software/systemd/inhibit/

That's what the gnome-remote-desktop RDP server does. It uses g_application_hold/release while the daemon is running to prevent the system from suspending.

I hope, this is the right place for this.

The best place is probably to file an issue in https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues . Somebody correct me if it should be in a different component.

You probably should report this against xrdp.

One problem is that xrdp doesn't inhibit sleep. But a second problem is "Although I complete disabled standby, the system goes to sleep".

@ulfklose How exactly did you disable it? Does it suspend even when logged in? Because the settings apply to your session only, so e.g. in the login screen it will still suspend. This is extremely confusing for users, I reported it 5 years ago here:
https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22

You can see how to configure the login screen here:
https://discussion.fedoraproject.org/t/gnome-suspends-after-15-minutes-of-user-inactivity-even-on-ac-power/79801

I also saw issues where changing the settings required a reboot to take effect, but can't reproduce that reliably. Something to try, though.

I can't speak for others, but this change caused a lot of problems for me this morning after upgrading from F37 to F38. I was working remotely over SSH, and GNOME kicked me out after 15 minutes:

Broadcast message from gdm@skylake on tty1 (Sat 2023-04-22 12:26:40 EDT):
The system will suspend now!
client_loop: send disconnect: Broken pipe

I had to drive across town to wake the machine back up so I could work on it.

The problem was solved with the following. Any energy savings are now lost.

systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

Created symlink /etc/systemd/system/sleep.target → /dev/null.
Created symlink /etc/systemd/system/suspend.target → /dev/null.
Created symlink /etc/systemd/system/hibernate.target → /dev/null.
Created symlink /etc/systemd/system/hybrid-sleep.target → /dev/null.

@ulfklose How exactly did you disable it? Does it suspend even when logged in? Because the settings apply to your session only, so e.g. in the login screen it will still suspend. This is extremely confusing for users, I reported it 5 years ago here:
https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22

I disabled standby using the GNOME setting which didn't seem to apply to SSH and RDP sessions.

You can see how to configure the login screen here:
https://discussion.fedoraproject.org/t/gnome-suspends-after-15-minutes-of-user-inactivity-even-on-ac-power/79801

I used these settings in my sleep.conf:

[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no

I also saw issues where changing the settings required a reboot to take effect, but can't reproduce that reliably. Something to try, though.

I rebooted my system several times, without any changes.

@noloader Same here. Fortunately the PC running Fedora is in the same room as I am but still, having no standby at all sucks.