Bug 2190021

I am not sure yet how to verify that gdm is actually the software responsible, but I did verify that in runlevel3 the computer does not attempt to suspend (checked using systemctl isolate runlevel3.target).

I changed two computers from gdm to sddm for login management, and the problem no longer occurs, so I think that does point pretty conclusively to gdm, or at least some setting which comes along with gdm.

See also bug 2188828 and the work around in https://discussion.fedoraproject.org/t/gnome-suspends-after-15-minutes-of-user-inactivity-even-on-ac-power/79801 seems to work after a reboot.

Yes, would have been useful to put in the F38 release notes.  
Contents of "Notable changes for desktop users" 
"    "

Seems like a miss for the release notes.

(In reply to Chris Caudle from comment #4)
> Yes, would have been useful to put in the F38 release notes.  
> Contents of "Notable changes for desktop users" 
> "    "
> 
> Seems like a miss for the release notes.

Nah.  DNF upgrade should not have change the sleep/suspend behaviour of the existing install.

A few points/suggestions/whatever:

0) I understand this change was made in order to get some sort of "Energy Star" rating or something, and that's why it can't just be reverted. That's understandable, but I can think of a few things that might be done to make it less disruptive while maintaining this new badge of honor.

1) Even though the setting that controls this is taking effect before logging in, and is not a part of the *user's* config, it should be accessible and settable from the gnome desktop settings app under "Power". Something this major should be discoverable in the UI, rather than requiring a google search followed by a cut-paste of an obscure command found in the middle of a forum discussion.

2) Such a major change in behavior should not happen automatically as the result of an OS version upgrade - if it must be made the default, it should only be the default for new installs. Think of the case of an unattended remote upgrade using dnf system-upgrade - the user would download the new packages, then run "dnf system-upgrade reboot" and forget about it while the packages are being upgraded; most likely they would try another login at a time after the upgrade has completed *and the 15 minute suspend timeout has passed*, and so the machine would already be suspended. "Damn! The upgrade failed and now my box in the closet in Nevada/Wyoming/Poughkeepsie/wherever is bricked!" :-(. (Seriously, I can envision this happening *a lot*, and people won't be happy about it).

3) During installs, maybe this setting can default to "suspend when idle", but there should be a very visible checkbox to disable it so that everybody is aware of this behavior and able to change it.

4) The definition of "idle" could certainly use some refinement. Note everyone who installs Fedora Workstation actually uses it as a desktop system. I install Workstation rather than Server because I do like to occasionally login to the desktop for certain things, but 95% of the time the video output isn't even connected to anything.

5) Although I haven't had a chance to experience it, some commenters on the fedora discussion forum have said that "dnf update" erases the "fix" to the suspend; I suppose this might happen when gdm itself is updated? Anyway, that definitely needs to be fixed (thinking about it - the fact that the setting is overridden during package upgrades means that an unattended upgrade of Fedora Workstation to F38+ is essentially impossible).

When my Fedora 38 Workstation system doesn't respond to ssh I use "wol" wake-on-lan, then ssh does work.  
This does require that ssh is being used from another system on the same LAN. It seems many Workstation
users aren't aware of wol (other distros use different names).

The hack I've used to fix this, after the fact:

For each user
- log in as user on GNOME desktop
- Settings: Power: Power Saving Options: Automatic Suspend: Off
- log out

For gdm:
sudo -u gdm dbus-run-session gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type nothing

For other Desktop Environments: ??

Unfortunately this setting is per-user.  Is that a clean global version?
I understand that the Fedora Server version does not have this porblem -- how is that configured?

> I understand that the Fedora Server version does not have this
> porblem -- how is that configured?

The package fedora-release-identity-server contains an override file
that previously was part of the gnome-settings-daemon package.
Namely: /usr/share/glib-2.0/schemas/org.gnome.settings-daemon.plugins.power.gschema.override

Actually there has always been a way of overriding dconf settings
for all users on the system.  You should find that the file 
/etc/dconf/profile/user (part of dconf) contains among other things
the string "system-db:site" which means you can put things in
/etc/dconf/db/site.d and then do "sudo dconf update" to update
the site settings.  It would look like this unless I'm much mistaken:

[org/gnome/settings-daemon/plugins/power]
sleep-inactive-ac-timeout=0

@imc.ac.uk thanks!

Philosophical question: why is powering off the whole machine a DE thing?  Should it not be a system-wide policy, for all DEs, perhaps in the form of a systemd setting?  Even within one DE, a per-user policy for this feels wrong to me -- it affects the whole computer, not just the console user.  On the other hand, screen blanking does seem to naturally be a per-user setting -- it only affects the user at that screen.
(My expectations were formed on UNIX before there were UNIX workstations.)

This message is a reminder that Fedora Linux 38 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '38'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 38 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21.

Fedora Linux 38 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.