Software > Operating Systems and Porting

Debian / GNOME default sleep settings: guaranteed crash

(1/2) > >>

pocock:

I did a fresh Debian install on one system and then left it at the GNOME login screen while making a phone call.

When I came back, the screen was frozen, SSH was not working any more but the CPUs and fans still active.

I rebooted it, checked the log and found that it had tried to sleep and managed to become frozen.

It is probably a good idea to track this with bug reports in both Debian and GNOME and change their default settings on ppc64le.

However, is there anything that can be done at a lower level, for example, in the kernel, to reject the sleep attempt rather than letting the system get into this frozen state?  If that could make it appear stable for every OS it would be much better than fixing it in one distribution at a time.

It was kind of obvious to me what had happened before I even looked in the logs but I can imagine some users might get a fright

MauryG5:
Hi Daniel, I remember this happening to me when I was using Ubuntu in version 20.04. If I left the computer for a while without using it, it would go to sleep with a black screen but when I tried to restore it from that state, the computer never recovered and crashed completely and you had to restart it. On Debian it never happened to me to be honest, I thought at the time that it was one of the many small Ubuntu bugs on Power but on Debian honestly I never tried to make it go to stand-by and then resume it ...

pocock:

If you make a fresh install of Debian with GNOME and then go and look at the default Settings panel for Power, you will see "Power Saving" default setting

The Debian wiki has some notes about systems which should never go to sleep.  In particular, they show some settings in systemd so it seems this can't just be fixed by changing the settings in GNOME


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

--- End code ---

This default is one of many ways where systemd appears to diverge from a traditional UNIX-like system.

You can check the current status of a system by checking each of those targets with the status command:


--- Code: ---$ sudo systemctl status sleep.target
● sleep.target - Sleep
     Loaded: loaded (/lib/systemd/system/sleep.target; static)
     Active: inactive (dead)
       Docs: man:systemd.special(7)

--- End code ---

and on a system where the target was disabled:


--- Code: ---$ sudo systemctl status sleep.target
● sleep.target
     Loaded: masked (Reason: Unit sleep.target is masked.)
     Active: inactive (dead)
[code]
--- End code ---

MauryG5:
Just today I accidentally hit a key dedicated to sleep on my keyboard and in fact it made the problem of going to sleep and then it never recovered, forcing me to restart everything. I gave that command you reported and in fact the result is: mauriziop9 @ debian: ~ $ sudo systemctl status sleep.target
[sudo] mauriziop9 password:
● sleep.target - Sleep
      Loaded: loaded (/lib/systemd/system/sleep.target; static)
      Active: inactive (dead)
        Docs: man: systemd.special (7)

Corvidae:
This isn't the best solution because it requires recompiling the kernel, but if you disable CONFIG_SUSPEND in the kernel config it should make it impossible for it to happen. From what I can tell, the s2idle state linux provides when suspend is enabled "works" in that it enters that state, but wakeup sources don't seem to work, so you can never get out of it.

Navigation

[0] Message Index

[#] Next page