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)
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.
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'.
(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".
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.
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
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).
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.
> 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).
This bug is accepted as Prioritized one. It will be brought to Workstation WG asking for taking an action.
> 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).
> The verification command should be: Oops, yeah, copypasta mistake :)
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.org.
(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
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
> 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.
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.
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.
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.
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.