Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 680198 - >=gnome-base/gdm-3.28: System suspends after 20 minutes
Summary: >=gnome-base/gdm-3.28: System suspends after 20 minutes
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: gnome-3.30
  Show dependency tree
 
Reported: 2019-03-13 08:36 UTC by Bernd Feige
Modified: 2019-03-26 14:50 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Feige 2019-03-13 08:36:20 UTC
See https://gitlab.gnome.org/GNOME/gnome-control-center/issues/22 and https://wiki.archlinux.org/index.php/GDM#GDM_auto-suspend_.28GNOME_3.28.29

Solution is:
 sudo -u gdm dbus-launch gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
 sudo -u gdm dbus-launch gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'nothing'

Apparently the difference in behavior comes from a change in gnome-settings-daemon (https://gitlab.gnome.org/GNOME/gnome-settings-daemon/commit/2fdb48fa) setting the default action to suspend after 20min. While that may make sense for user sessions and can be changed by the user in gnome-control-center, the behavior in GDM cannot be changed using the UI.

It is obvious that this leads to a critical problem in all servers booting to GDM: The systems will suspend after 20 minutes. Needless to say, many desktops and servers are not prepared for a suspend and will likely not come up cleanly, resulting in data loss. So at least the defaults for GDM need to be fixed.
Comment 1 Mart Raudsepp gentoo-dev 2019-03-13 21:44:38 UTC
I'm curious why servers have GDM though.
Changing this kind of defeats the EU regulation point for us though, no?
I mean when changing this in a way that affects laptops too.
That said, I'm probably more in favor of not making people visit data centers than following some regulation to the letter
Comment 2 Leho Kraav (:macmaN @lkraav) 2019-03-15 22:16:19 UTC
I have a machine that's successfully combined as a media center, for years.
Comment 3 Pacho Ramos gentoo-dev 2019-03-19 22:35:38 UTC
Personally I would suspend in 20 mins *only* if running in battery, not plugged. Another case... for example, when I leave my laptop connected and updating... I wouldn't like to return as see that compilation stopped in 20 mins because it was suspended
Comment 4 Mart Raudsepp gentoo-dev 2019-03-20 05:20:40 UTC
I believe the problem here should be only if having the screen be on GDM. If you log in, then your users settings already apply, which can be changed. So that concern about upgrades suspending applies if you left the machine in GDM login screen and do the upgrades remotely or something like that.

The upstream issue has a suggestions for

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

So basically setting this only for ac-timeout would be sufficient, leaving battery-timeout untouched?
Comment 5 Leho Kraav (:macmaN @lkraav) 2019-03-20 05:57:02 UTC
Makes sense enough to me.
Comment 6 Bernd Feige 2019-03-20 09:16:40 UTC
Yes, even more compelling to me is that a system with a battery is quite likely to be able to suspend. In my experience, Linux suspend is broken on many desktops today and if they try they won't come up cleanly, so that the final result is similar to just switching off system power without any shutdown.

I wonder if I am missing something obvious here - if it's a misconfiguration on my side allowing suspend to be initiated on systems with broken suspend. I know that suspend can be disabled in the kernel config, but up to now this was not strictly necessary, since you knew which systems you shouldn't try to suspend so you didn't do it. Now gdm does it without asking...
Comment 7 Mart Raudsepp gentoo-dev 2019-03-26 14:26:50 UTC
I'll just change the default for everyone (default for regular users too) to never taking sleep actions on AC power and call it a day.
Comment 8 Larry the Git Cow gentoo-dev 2019-03-26 14:42:51 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f4f95aa8d56dbae6cd426b47df1be818e64c88ea

commit f4f95aa8d56dbae6cd426b47df1be818e64c88ea
Author:     Mart Raudsepp <leio@gentoo.org>
AuthorDate: 2019-03-26 14:41:10 +0000
Commit:     Mart Raudsepp <leio@gentoo.org>
CommitDate: 2019-03-26 14:42:15 +0000

    gnome-base/gnome-settings-daemon: don't automatically suspend on AC power
    
    Closes: https://bugs.gentoo.org/680198
    Package-Manager: Portage-2.3.52, Repoman-2.3.12
    Signed-off-by: Mart Raudsepp <leio@gentoo.org>

 ....settings-daemon.plugins.power.gschema.override |   2 +
 .../gnome-settings-daemon-3.30.2-r1.ebuild         | 137 +++++++++++++++++++++
 2 files changed, 139 insertions(+)
Comment 9 Mart Raudsepp gentoo-dev 2019-03-26 14:50:26 UTC
I went with ac-type default change, instead of ac-timeout, because if ac-timeout is 0, then gnome-control-center sets the settings to ac-timeout=3600 and ac-type='nothing', which results in an explicitly set setting, which won't be affected by any future default changes.
So instead just setting to ac-type='nothing' directly in the override instead, unlike Fedora, who sets ac-timeout=0, then the greyed out option in control-center remains at 20 minutes, not gets set to 30 minutes.