27

I have a machine that I access only via SSH that I just updated to Debian 10 a couple of days ago. Since the update it seems to be going to sleep when it is inactive. This has never happened with previous updates like from 7 to 8 or from 8 to 9. It seems like maybe the sleep settings have reverted to a default state. How can I view and edit the power and sleep settings in the command line? Any guidance much appreciated. Thanks!

1

5 Answers 5

31

I ran into this with gdm3 after upgrading to Debian 10: whenever the computer was left at the initial login screen, it would go to sleep after a while.

To fix this, I had to edit the power settings for GNOME when running the gdm3 session; these are stored in /etc/gdm3/greeter.dconf-defaults, and the lines to edit are those in the “Automatic suspend” section at the end of the file:

# Automatic suspend
# =================
[org/gnome/settings-daemon/plugins/power]
# - Time inactive in seconds before suspending with AC power
#   1200=20 minutes, 0=never
# sleep-inactive-ac-timeout=1200
# - What to do after sleep-inactive-ac-timeout
#   'blank', 'suspend', 'shutdown', 'hibernate', 'interactive' or 'nothing'
sleep-inactive-ac-type='blank'
# - As above but when on battery
# sleep-inactive-battery-timeout=1200
# sleep-inactive-battery-type='suspend'

Specifically, I changed sleep-inactive-ac-type to 'blank'. Despite its name, this isn’t a template file which should be copied; the change must be made in the /etc/gdm3/greeter.dconf-defaults file itself. The changes are taken into account after restarting the gdm3 service.

I didn’t have to make any changes to the systemd or logind setup; this means that if I want to, I can still suspend the system manually.

3
  • Did you copy greeter.dconf-defaults to greeter.dconf ? and restart some service?
    – Roman
    Oct 8, 2019 at 10:19
  • 1
    @Roman the file really is greeter.dconf-defaults, it doesn’t need to be renamed (it’s taken into account because there’s a symlink to it in /usr/share/gdm/dconf). You do need to restart the gdm3 service for the change to be taken into account. Oct 8, 2019 at 10:58
  • 1
    There seem to be a couple of Debian bug reports for this issue: bugs.debian.org/cgi-bin/bugreport.cgi?bug=896083 & bugs.debian.org/cgi-bin/bugreport.cgi?bug=893964 . Seems to be quite intentional though, and no sign a reversion to the old non-suspending behaviour is planned: there's a claim that the need for the change came about "to comply with European and American power-saving regulations".
    – timday
    Apr 23, 2020 at 14:24
20

you can try the following based on your needs:
Disable suspend and hibernation:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

To re-enable hibernate and suspend use the following command:

sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target

If you just want to prevent suspending when the lid is closed you can set the following options in /etc/systemd/logind.conf:

[Login]
HandleLidSwitch=ignore
HandleLidSwitchDocked=ignore

restart the service or reboot your machine

systemctl restart systemd-logind.service
4

The situation tricky and stupid at the same time. I've tried a lot of variants to guess why it's not working.

The Solution: (**Tested and Works on Debian 10 with GNOME on Laptop HP Elitebook) There are TWO greeter.dconf-defaults files First in /etc/gdm3/greeter.dconf-defaults and second in /usr/share/gdm/greeter.dconf-defaults.

The main idea that TWO this files MUST BE THE SAME! Edit /etc/gdm3/greeter.dconf-defaults from ROOT and UNComment some LINE below!!!

Find

# sleep-inactive-ac-timeout=1200 #--default
sleep-inactive-ac-timeout=0      # new

sleep-inactive-ac-type='blank'

# - As above but when on battery
sleep-inactive-battery-timeout=0
sleep-inactive-battery-type='blank'

Just SAVE IT and copy to PATH /usr/share/gdm/greeter.dconf-defaults and reboot.

Note that these files MUST BE THE SAME!

P.S I think it's a bug because, after you edit /etc/gdm3/greeter.dconf-defaults, dpkg-reconfigure gdm3 --doesn't work proper (Should change /usr/share/gdm/greeter.dconf-defaults).

2

I made the changes in /etc/gdm3/greeter.dconf-defaults and indeed this does stop the sleep while waiting at the GDM screen. However if you do logon to, e.g., gnome, then again after about 20 mins the same sleep reoccurs.

N.B. I have set the gnome desktop (privacy) to NOT lock the screen at idle. This is presumably working as when it awakes from sleep (by tapping keyboard) the screen is not locked and the desktop is "as left" ...

N.B. Running a "long job" at the physical display (via X, not tested on TTY) delays the sleep. Activity on ssh session (as above) does not.

2

Apparently there are two layers to the "suspend event processing":

A) the part where the suspend action is carried out (the computer is put to sleep, technically) and

B) the part that decides when a suspend is needed, and asks for the suspend action to happen.

Under the hood, there's the "implementation" of the suspend action. But, the "non-interactive guts" under the hood are not likely to monitor user activity and suspend the system if the human goes out to lunch...

The desktop environment, OTOH, is prone to keeping an eye on user interaction and "winding down" after a timeout.

The solution suggested by @Stephen Kitt and finalized by @Ivan addresses the desktop environment taking the intiative to decide when a system is tired of being awake. More specifically: it tackles the GDM = the "display manager" stage. The display manager is the Xwindows equivalent of "winlogon", i.e. the environment before a user logs in. Elsewhere, people have pointed out that without a further configuration, once a user logs in to the graphical desktop, the system can still go to sleep on timeout. I'd explain this by the "X session taking over" (or window manager or whatever). This is probably the bit that you can configure via the "settings" app within a logged-in desktop session, namely the "Power" dialog has a particular widget to enable/disable the suspend on timeout.

Under the hood, it turns out that systemd has claimed this playground too. But, I've found sources that do NOT recommend masking the relevant sleep.target, suspend.target, hibernate.target and hybrid-sleep.target - as reportedly, this can have adverse side-effects.

There is possibly a better way: edit /etc/systemd/sleep.conf and activate the following two lines:

AllowSuspend=no
AllowHibernation=no

Not sure what systemd service to restart, in order for the new configuration to take effect. I suggest that you just restart the whole Linux machine.

See also

man systemd-sleep
man systemd-sleep.conf

If you still have acpid in the system, you may try enabling its debug mode and have it log events into syslog - edit /etc/default/acpid and enter

OPTIONS="-d -l"

next you need to

systemctl restart acpid

and then you can also

grep acpid /var/log/daemon.log

...yet this whole course of action (acpid) seems nowadays largely moot. The interesting stuff nowadays happens within systemd, acpid is possibly only any good to run custom shell commands in response to ACPI buttons and whatnot. Theoretically you could glean the "event name" of the suspend event and then make an acpid rule to "drop" that event, but to me the jury's out on whether this has some practical effect or not, in the way of preventing the event from causing actual suspend action.

1
  • Has anyone found the answer to this part "Not sure what systemd service to restart, in order for the new configuration to take effect"? It seems crazy that it isn't documented somewhere obvious. Nov 10, 2021 at 14:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.