Bug 1558485 - auto-suspend can't be disabled when GDM is active
Summary: auto-suspend can't be disabled when GDM is active
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rui Matos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: PrioritizedBug https://fedoraproject....
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-20 10:26 UTC by Kamil Páral
Modified: 2020-03-26 23:30 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-28 22:35:51 UTC
Type: Bug


Attachments (Terms of Use)

Description Kamil Páral 2018-03-20 10:26:08 UTC
Description of problem:
With GNOME 3.28, system automatically suspends after 20 minutes. That can be adjusted/disabled in system settings - however, it only applies to that particular user session. When GDM is the active screen, the system still suspends after 20 minutes, and there's no way to configure that. That affects e.g. the following use cases:

a) fast user switching - see https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/18 for a detailed description
b) sharing files - if you start your computer just to access your files remotely (i.e. presenting your wedding pictures on your living room laptop/TV from your desktop in study room), there's no reason to log in - but it means your system will auto-suspend
c) working over ssh - starting the system either locally or remotely just to connect over ssh means your system will get suspended in 20 minutes regardless of your activity in ssh console. This also applies e.g. when debugging graphical login failures.
d) and probably many more

Version-Release number of selected component (if applicable):
gnome-shell-3.28.0-1.fc28.x86_64
mutter-3.28.0-1.fc28.x86_64
gnome-settings-daemon-3.28.0-1.fc28.x86_64
gdm-3.28.0-1.fc28.x86_64

How reproducible:
always

Steps to Reproduce:
1. disable auto-suspend in your GNOME settings
2. log out to GDM
3. see system suspend after 20 minutes
4. try to find a way how to disable that (I currently don't know the solution to this, it's definitely not easy and straightforward)

Comment 1 Kamil Páral 2018-03-20 10:28:49 UTC
Nominating this as a PrioritizedBug, because I believe some of our advanced users will be extremely angry at us if we keep it this way. At the same time, I'm not sure if we have a way to classify this as a release blocker.

Comment 2 Adam Williamson 2018-03-20 19:31:18 UTC
Re 4., the Alternative Fedora Wiki has something on this:

https://wiki.archlinux.org/index.php/GDM#DConf_configuration

I think I've done it by running gsettings as 'gdm' before, though it's a bit of a pain as the account is set up by default such that you can't really switch to it. I think I either hacked up the account definition temporarily, or wrote a script that made the changes and ran the script with 'runuser'.

Comment 3 Michal Jaegermann 2018-03-21 01:18:04 UTC
(In reply to Adam Williamson from comment #2)

> ... or wrote a script that made the changes and ran the script with 'runuser'.

Apparently that approach would be too simple.  When I tried what will happen with "runuser -u gdm gsettings list-recursively" I got, repeated many times over, this:

dconf-CRITICAL **: unable to create directory '/run/user/0/dconf': Permission denied.  dconf will not work properly.

Attempts to use 'runuser' with other options ended up consistently with "This account is currently not available".  It seems that hacking gdm account would be a way to go.  Not that "friendly".

Comment 4 Lukas Ruzicka 2018-03-22 07:16:39 UTC
And I would also like to report a use case that Kamil has not mentioned. This one also drives me mad.

I use Fluxbox, which somehow manages to lock the suspend, so it works as required for the whole time I am using the computer. However, when I exit Fluxbox, the GDM kicks in (and thinks that I have been inactive the whole time) and suspends immediately, so I do not have a chance to power off the computer via the GDM menu. Instead I have to wake it up and then shut down.

I tried to use my root account to log as user gdm and tried to use gsettings to switch it off, but it did not work for me and it still behaves the same. I wonder, if this could be set via /etc/gdm/custom.conf. That would be the most logical way to do it.

Comment 5 František Zatloukal 2018-03-23 11:32:03 UTC
This might be of interest to Server SIG. When you have F28 Server and install 'gnome-desktop' group and set it to start in graphical.target (because some admins prefer working in a desktop environment), the server also suspends every 20 minutes. Regardless of any active ssh sessions, important services running, etc.

Reproducer:
1. Install F28 Server (no autosuspend by default)
2. # dnf group install gnome-desktop
3. # dnf install mesa-dri-drivers (to work around bug 1559797)
4. # systemctl set-default graphical.target
5. # systemctl enable gdm
6. # reboot
7. Autosuspend in 20 minutes

Comment 6 Ray Strode [halfline] 2018-03-23 17:30:10 UTC
So the best reference is the gnome sysadmin guide:

https://help.gnome.org/admin/system-admin-guide/stable/login.html.en

it doesn't cover this setting in particular, but it does cover others like for instance, disabling the user list:

https://help.gnome.org/admin/system-admin-guide/stable/login-userlist-disable.html.en

so instead of:

[org/gnome/login-screen]
# Do not show the user list
disable-user-list=true

you'd have

[org/gnome/settings-daemon/plugins/power]
# Do not autosuspend
sleep-inactive-ac-type='nothing'
sleep-inactive-battery-type='nothing'

(if you run 'dconf dump /' in the user session, it should dump all the changes currently applied to the users session in the appropriate format).

Comment 7 Ray Strode [halfline] 2018-03-23 17:34:36 UTC
also if you have gdm from updates-testing you can drop the file in /etc/dconf/db/local.d and have it apply for the login screen and all user sessions at the same time.

Comment 8 fednuc 2018-04-04 23:54:49 UTC
> the Alternative Fedora Wiki

I'm stealing this name :D

But in this case they've made things over-complicated.

To disable suspend for GDM, just run:

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

And verify with:

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

(Similarly for battery if applicable).

Comment 9 Jan Kurik 2018-04-25 19:34:24 UTC
This bug is accepted as Prioritized one. It will be brought to Workstation WG asking for taking an action.

Comment 10 Bernd 2018-07-29 06:18:37 UTC
> And verify with:
> 
> sudo -u gdm dbus-launch gsettings set
> org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type nothing

The verification command should be:

sudo -u gdm dbus-launch gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type

It shows 'suspend' before and 'nothing' after the set command (including the apostrophes).

Comment 11 fednuc 2018-07-29 06:40:03 UTC
> The verification command should be:

Oops, yeah, copypasta mistake :)

Comment 12 Ben Cotton 2018-08-02 20:22:44 UTC
This bug has been accepted as a PrioritizedBug. Since it is still in the "NEW" state, the triage team will revisit it at the 2018-08-29 meeting. If you have any updates, you can provide them here or email triage@lists.fedoraproject.org.

Comment 13 Edgar Hoch 2018-08-10 14:39:25 UTC
(In reply to Bernd from comment #10)
> sudo -u gdm dbus-launch gsettings get
> org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type

I think dbus-run-session should be used instead of dbus-launch, because otherwise each invocation leaves a running dbus-daemon process around... (that needs to be killed manually).

> It shows 'suspend' before and 'nothing' after the set command (including the
> apostrophes).

I use 'blank' to instead of 'nothing' to let the screen go into powersave mode.

Here my values as an example:

# sudo -u gdm dbus-run-session gsettings list-recursively org.gnome.settings-daemon.plugins.power
org.gnome.settings-daemon.plugins.power power-button-action 'suspend'
org.gnome.settings-daemon.plugins.power idle-dim true
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'blank'
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 600
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'suspend'
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 600
org.gnome.settings-daemon.plugins.power ambient-enabled true
org.gnome.settings-daemon.plugins.power idle-brightness 30

Comment 14 Edgar Hoch 2018-08-10 14:55:18 UTC
With settings as shown in comment #13, our systems doesn't suspend.

It may be relevant that gdm-3.28.2-1.fc28.x86_64 seems to ignore /etc/dconf/profile/gdm . It seams only read /usr/share/dconf/profile/gdm .

This means that most instructions from internet, which suggest to create /etc/dconf/profile/gdm and something like /etc/dconf/db/gdm.d/myconfigfile, doesn't work for Fedora 28 anymore.

Dconf settings need to be written in a file in /etc/dconf/db/site.d/ or /etc/dconf/db/local.d/ instead, and "(umask 002 ; dconf update )" still needs to be run after changes in files in these directories.


I had no problems with auto-suspend, because I always set some default parameters globally for all our users, which includes sleep-inactive settings. Here some values I set in a file in /etc/dconf/db/site.d/ :


[org/gnome/settings-daemon/plugins/power]
sleep-inactive-ac-timeout=600
sleep-inactive-ac-type='blank'
sleep-inactive-battery-timeout=600

[org/gnome/desktop/session]
idle-delay=600

[org/gnome/desktop/screensaver]
lock-delay=180
status-message-enabled=false

[org/gnome/login-screen]
disable-user-list=true

[org/gnome/shell]
always-show-log-out=true

[org/gnome/shell/overrides]
button-layout=':minimize,maximize,close'

[org/gnome/shell/window-switcher]
current-workspace-only=false

Comment 15 fednuc 2018-08-10 16:31:52 UTC
> I think dbus-run-session should be used instead of dbus-launch, because otherwise each invocation leaves a running dbus-daemon process around... (that needs to be killed manually).

Yeah, in fact I found that out since my original comment :)

I think I might have found some problems with using dbus-run-session too though (possibly that if an existing user daemon was already running, the settings didn't stick?)

I ended up using something along the lines of this in a script, to use the existing daemon or spawn a new one:

buspath="/run/user/$(id -u)/bus"
if [[ -S "$buspath" ]]; then
    DBUS_SESSION_BUS_ADDRESS=unix:path="$buspath" "$@"
else
    dbus-launch --exit-with-session "$@"
fi

Presumably dbus-run-session could be substituted in the else clause though.

Comment 16 Ray Strode [halfline] 2018-09-12 15:49:20 UTC
So at the moment in fedora we ship this setting override:

╎rstrode@halfstation〉⎛/srv/sources/pkgs/gnome-settings-daemon⎞ ⌜11:46 AM⌟
╎❯ cat org.gnome.settings-daemon.plugins.power.gschema.override
[org.gnome.settings-daemon.plugins.power]
sleep-inactive-ac-timeout=0

this affects user sessions and the login screen.

I think that mitigates the brunt of this bug. Arguably what's left is that control-center should migrate the user settings to the login screen session on single user systems.

That should probably be tracked upstream, not here.

Comment 17 Ben Cotton 2018-09-26 20:12:23 UTC
In today's Prioritized Bugs meeting, we voted to consider this resolved for the purposes of that process since Fedora ships with a setting override that addresses. most of the issue.

Comment 18 Ben Cotton 2019-05-02 20:50:07 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. 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 Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 19 Ben Cotton 2019-05-28 22:35:51 UTC
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 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 please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

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


Note You need to log in before you can comment on or make changes to this bug.