@anon5065024 That’s is my situation. I implemented all the recommended changes, and noting worked for me. AT the end I had to disable GDM and enable KDM.
Do we have straightforward instructions on how to permanently disable this misfeature?
This worked for me:
sudo -u gdm dbus-run-session gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
I originally found it after digging through this discussion and seeing an example with a non-0 timeout. It really should be a single button somewhere in the UI (and/or settable via a one line config file that can be injected somewhere into /etc), since I envision that I (and many others) will need to do it for every future new install of Fedora.
Not only instal, but also updates. After every single “dnf -y update”, those settings are overwritten and the system returns back to the previous behaviour. Currently, for the sake of surviving updates, the gdm command should be executed at every single system reboot.
This soluton is ment for users who use the GDM as login manager.
And in first case for users who not use SSH to the system.
All other users who have a different setup please create a own topic with your own specifications/situation so that we can give you assistance.
This is overwriting the below (of course you also have to check/set automatic suspend off in the settings.)
while doing this:
sudo -u gdm dbus-run-session gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
I tested on F37 where gives an error but still works (missing option in gnome shell).
Fedora 38 works here my listings:
sudo -u gdm dbus-run-session gsettings list-recursively org.gnome.settings-daemon.plugins.power
org.gnome.settings-daemon.plugins.power ambient-enabled true
org.gnome.settings-daemon.plugins.power idle-brightness 30
org.gnome.settings-daemon.plugins.power idle-dim true
org.gnome.settings-daemon.plugins.power power-button-action 'suspend'
org.gnome.settings-daemon.plugins.power power-saver-profile-on-low-battery true
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 900
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'suspend'
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 900
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'suspend'
Hi L.S>,
I am one of the early posters on this thread. I use GDM to login locally but also use SSH for remote access. Should I create a new thread?
I’d like the Fedora Devs to admit that they made a serious error in not properly communicating this change to the users and to also provide an immediate patch to remove all power management suspend/kill action from the system by user choice.
There have been claims this was done to satisfy some ‘efficiency’ standard and that may or not be completely accurate, but in any case there should be a way for ME to decide HOW MUCH POWER my system uses and NOT have that forced upon me.
Fedora software is provided at no cost to all users and the efforts of the Fedora team are appreciated. However, they make mistakes and this is a big one that needs formal correction quickly.
If you want to support the project and find as soon as possible a solution who fits for your workflow, then yes.
Just stand out of the topic here, while convince others that the developers have to make everything as you want to have it.
We are using here a sponsored workspace, Fedora is the upstream Open Source Project of RH who serves among other things to test new technologies, this seams to be one.
Participate as proposed or stand out. Same to @afberendsen. What you are doing is going in direction of seelioning arguing without any action to keep others busy responding you.
I don’t think anyone is intentionally “sealioning” or attempting to just clog up the works without contributing anything (first time I’ve seen that term, but I completely understand the behavior it’s referring to, and I don’t see that here). A more accurate explanation is that they encountered the problem out of the blue after updating to F38 (as I did), asked around, did a couple google searches, and ended up on this posting, which seems to have some respondents who might be able to do something about this (as rjones calls it, and I agree) “misfeature”. And now they are “discussing” it, which I guess is the point of a discussion forum.
Rather than starting another thread on this same forum though (which would likely lead to just more disparaging comments about “complaining without doing anything”), I would suggest it might be more productive to make a comment in the bugzilla report that was created about this issue:
2190021 – gdm suspends computer preventing remote login; behavior change after upgrade to 38
(or it might not - sometimes Fedora bugzillas get a good response, sometimes not, depending on how busy the assignees are and how relevant the issue is to their current “day job priorities”. But at least the intent of bugzilla is to provide formal tracking of issues until they are resolved in some manner, for better or worse)
Based on Matt’s comments here and elsewhere, it doesn’t seem like the default is going to be changed back (which is unfortunate from my PoV, but there are at least documented “reasons”, so I guess I can live with it :-)) but possibly a change could be discussed over in bugzilla that would at least make the necessary change to disable it more easily discoverable, and possibly even prevent the change in behavior during upgrades and only make the change for new installs (especially since the new behavior breaks a longtime major assumption of, well, just about everybody that could leave some people in serious trouble - I’m just imagining the sea of users who will perform an unattended upgrade to their machines in remote closets and garages all over the world in the upcoming months, and are then very disappointed that the upgrade “apparently failed” and the machine is no longer reachable; I’m thinking back to how I would have reacted if this change had been put in during the time I had a backup server in a garage in Wyoming, but was living in Istanbul for the year; I did unattended upgrades of that system (using “dnf system-upgrade”) twice during that year (and several times in the years following, just not quite so remote) and it went off without a hitch every time; would not have happened today).
(BTW, I don’t really think that Red Hat’s sponsorship of Fedora has anything to do with this discussion. I’ve been trying to think of what difference it could make, and can’t come up with anything other than the generic “Hey, it’s free!”. We all understand that we aren’t paying for Fedora support; however, we also all want Fedora to be as good as it can be for the benefit of everybody in the community (not just ourselves), and so of course we’re going to voice our opinions - that in itself is a contribution of sorts, up to a point, and I don’t think we’ve exceeded that point yet)
And where have been all this voices while we made the beta tests?
I counted thru the whole topic … at least 7 new users who just show up to complain now?
Where have they been while we beta tested?
And why just showing up now on F38 ?
For all this who really need assistance, and want to create a own, on this discussion based topic please do the following:
On any your suitable request press on the chain Icon
It will open this info box:
Hit the “+ New Topic” and your request alias new topic will be linked to the post you chosen.
1 Like
Immaterial.
I normally do not participate in the beta tests, but do actively participate here. If I see a discussion about something that seems to match the symptoms I am experiencing I may choose to comment on it.
If something is missed in the beta testing then it strikes after I do the upgrade I would post about it.
The fact that “new users” are commenting on this thread, and that Fedora chose to activate the automatic suspend with the release of version 38 should not surprise one when all the affected users suddenly pop up to comment on the situation. It did, after all, affect (almost) everyone using fedora 38 in one way or another so the extra users that are making comments should hardly be unexpected.
It does seem odd that something affecting so many users could be missed in beta testing. I don’t know if there is tracking of beta tester coverage, but this should encourage more users to participate. I do my own tests using removable media before upgrading and was happy to see improvements to linux power management – too often I get called away for some “simple” issue that takes hours. Wake-on-lan has been useful.
Very well said Jeff.
@computersavvy Is there a reason you don’t want to share the problem and workaround you found, which might help some people here?
I asked before but saw no answer. What setting does Fedora Server use to suppress or not enable this behaviour? I hope it is a single global setting.
What files actually changed in F38 to implement the new policy?
The commit for Fedora’s server override is here:
https://src.fedoraproject.org/rpms/fedora-release/c/6f94a4dbbc29d2725f60d0f844530a63f4122999?branch=rawhide
The commit for the gnome-settings change is here:
https://src.fedoraproject.org/rpms/gnome-settings-daemon/c/c8f9665aca0617a921ec308a0f1d2741d92dc41d?branch=rawhide
The workstation pagure issue: https://pagure.io/fedora-workstation/issue/360
If you wanted to apply the override you would need to create that file in /usr/share/glib-2.0/schemas/ and then run sudo glib_compile_schemas /usr/share/glib-2.0/schemas/
If a user had been previously set up you may also need to run gsettings reset org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout
4 Likes
See my posts
and
and the one above
Additionally I used the gnome settings to disable auto suspend from within gnome, but the one that seems to have fixed it (semi-)permanently was masking the 4 targets
I do have a problem in that if I leave a chrome window open while the screen is locked it sometimes causes the system to crash. When I close chrome before walking away from the keyboard the system does not crash. I don’t think this has anything to do with the subject of suspend though.
1 Like
The proper way to ask for revert of the autosuspend is to contact Workstation WG. I think they also watch workstation-wg tag in Project Discussion . Link to this topic, to showcase that there are more people than just you who are not happy.
The proper way to file a bug if the recommended solution isn’t working is to file a bug against gnome-settings-daemon.
This is a discussion topic for the issue documentation, the developers aren’t reading it.
1 Like
Well, some of us are. But, yeah.
Can someone tell me how “energy-consumption certifications” is more important than having users?
Come on — that’s not a question in good faith.
But, I’ll answer a different one! How are energy certifications important for Linux to get new users?
We’ve known from user research — and just from questions on Ask Fedora — that getting a system installed with all the hardware working is the biggest barrier to wider adoption of Fedora Linux — and Linux desktop systems in general.
The best way around that is to get more vendors providing systems with Fedora Linux preinstalled. The only way to do that is for those vendors to meet government requirements. Including energy use.