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!
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
'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
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.
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
[Login] HandleLidSwitch=ignore HandleLidSwitchDocked=ignore
restart the service or reboot your machine
systemctl restart systemd-logind.service
The situation tricky and stupid at the same time. I've tried a lot of variants to guess why it's not working.
(**Tested and Works on Debian 10 with GNOME on Laptop HP Elitebook)
There are TWO
/etc/gdm3/greeter.dconf-defaults and second in
The main idea that TWO this files MUST BE THE SAME!
/etc/gdm3/greeter.dconf-defaults from ROOT and UNComment some LINE below!!!
# 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
Note that these files MUST BE THE SAME!
P.S I think it's a bug because,
after you edit
dpkg-reconfigure gdm3 --doesn't work proper (Should change
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.
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
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:
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.
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
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.