system suspends despite settings

[humphrey]

Hi,

My system appears to intermittently suspend after I upgraded from release 11.

System details are as follows.

$ lsb_release -a

Code: Select all

No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 12 (bookworm)
Release:	12
Codename:	bookworm

$ uname -a

Code: Select all

Linux Loek 6.1.0-17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) x86_64 GNU/Linux

$ upower --dump

Code: Select all

Device: /org/freedesktop/UPower/devices/DisplayDevice
  power supply:         no
  updated:              Fri 09 Feb 2024 11:26:09 (108912 seconds ago)
  has history:          no
  has statistics:       no
  unknown
    warning-level:       none
    percentage:          0%
    icon-name:          'battery-missing-symbolic'

Daemon:
  daemon-version:  0.99.20
  on-battery:      no
  lid-is-closed:   no
  lid-is-present:  no
  critical-action: HybridSleep

cinnamon-settings

Screen saver delay = 15 min
lock computer when put to sleep = off
lock computer after screen saver starts = off

turn off screen after = 30 min
suspend when inactive for = never
when power button is pressed = ask
enable hybrid sleep = off
enable hibernate after suspends = off


Any help would be appreciated.

[FreewheelinFrank]

What are Systemd settings?

Code: Select all

$ cat /etc/systemd/logind.conf

And GDM settings? (Not a Cinnamon user: I'm guessing GDM is the display manager, but please correct me if I'm wrong.)

Code: Select all

/etc/gdm3/greeter.dconf-defaults

[humphrey]

It is a remote system and I cannot log in to it now so I will reply tomorrow.

I am using the Cinnamon desktop with LightDM desktop manager (https://wiki.debian.org/LightDM).

[humphrey]

$ systemd-analyze cat-config systemd/logind.conf

Code: Select all

# /etc/systemd/logind.conf
[...]

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#UserStopDelaySec=10
#HandlePowerKey=poweroff
#HandlePowerKeyLongPress=ignore
#HandleRebootKey=reboot
#HandleRebootKeyLongPress=poweroff
#HandleSuspendKey=suspend
#HandleSuspendKeyLongPress=hibernate
#HandleHibernateKey=hibernate
#HandleHibernateKeyLongPress=ignore
#HandleLidSwitch=suspend
#HandleLidSwitchExternalPower=suspend
#HandleLidSwitchDocked=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#RebootKeyIgnoreInhibited=no
#HoldoffTimeoutSec=30s
#IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10%
#RuntimeDirectoryInodesMax=
#RemoveIPC=yes
#InhibitorsMax=8192
#SessionsMax=8192
#StopIdleSessionSec=infinity

$ cat /etc/gdm3/greeter.dconf-defaults

Code: Select all

cat: /etc/gdm3/greeter.dconf-defaults: No such file or directory

[FreewheelinFrank]

Not a Cinnamon user, so I can't test it, but does this command provide any information?

Code: Select all

$ gsettings list-recursively org.cinnamon.settings-daemon.plugins.power

Or maybe dconf-editor?

https://forums.linuxmint.com/viewtopic.php?t=302573

[humphrey]

$ gsettings list-recursively org.cinnamon.settings-daemon.plugins.power

Code: Select all

org.cinnamon.settings-daemon.plugins.power backlight-helper-force false
org.cinnamon.settings-daemon.plugins.power backlight-helper-preference-order ['firmware', 'platform', 'raw']
org.cinnamon.settings-daemon.plugins.power button-hibernate 'hibernate'
org.cinnamon.settings-daemon.plugins.power button-power 'interactive'
org.cinnamon.settings-daemon.plugins.power button-suspend 'suspend'
org.cinnamon.settings-daemon.plugins.power critical-battery-action 'hibernate'
org.cinnamon.settings-daemon.plugins.power idle-brightness 30
org.cinnamon.settings-daemon.plugins.power idle-dim-ac false
org.cinnamon.settings-daemon.plugins.power idle-dim-battery true
org.cinnamon.settings-daemon.plugins.power idle-dim-time 90
org.cinnamon.settings-daemon.plugins.power inhibit-lid-switch true
org.cinnamon.settings-daemon.plugins.power lid-close-ac-action 'suspend'
org.cinnamon.settings-daemon.plugins.power lid-close-battery-action 'suspend'
org.cinnamon.settings-daemon.plugins.power lid-close-suspend-with-external-monitor false
org.cinnamon.settings-daemon.plugins.power lock-on-suspend false
org.cinnamon.settings-daemon.plugins.power percentage-action 3
org.cinnamon.settings-daemon.plugins.power percentage-critical 4
org.cinnamon.settings-daemon.plugins.power percentage-low 10
org.cinnamon.settings-daemon.plugins.power sleep-display-ac 1800
org.cinnamon.settings-daemon.plugins.power sleep-display-battery 1800
org.cinnamon.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
org.cinnamon.settings-daemon.plugins.power sleep-inactive-ac-type 'suspend'
org.cinnamon.settings-daemon.plugins.power sleep-inactive-battery-timeout 0
org.cinnamon.settings-daemon.plugins.power sleep-inactive-battery-type 'suspend'
org.cinnamon.settings-daemon.plugins.power time-action 240
org.cinnamon.settings-daemon.plugins.power time-critical 420
org.cinnamon.settings-daemon.plugins.power time-low 1200
org.cinnamon.settings-daemon.plugins.power use-time-for-policy false

I am not sure I understand the differences between the cinnamon-settings I reported originally and what I see here above.

I installed dconf-editor. What info do you need from there?

[FreewheelinFrank]

Output should be in code tags please. Edit posts, highlight output and click the </> button.

dconf-editor is just an alternative way of getting the same information. As I am not a Cinnamon user, I could not test if that command would work. As it did, you do not need to use it (although it may be useful for editing settings).

The output of the command is obviously fuller than the settings you reported. Whether there is anything that explains your issue is another question.

Is the machine a laptop? The only scenario I can think of where the machine would sleep (actually hibernate) is if it was a laptop and there was a power cut or the power supply is failing, in which case it would hibernate on low battery, which for an older laptop could be quite a short period.

Are you logged in when the machine goes to sleep? If you are not logged in, it could be whatever DM greeter you have installed that has a sleep timer.

If neither of those scenarios is true, please provide some system information with

Code: Select all

$ inxi -Fxz

(Install package inxi if not already installed.)

[humphrey]

I have edited the post as you requested. I hope it is now alright.

The machine is a barebones system, running 24/7, always logged in.

System info as follows.

$ inxi -Fxz

Code: Select all

System:
  Kernel: 6.1.0-17-amd64 arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    Desktop: Cinnamon v: 5.6.8 Distro: Debian GNU/Linux 12 (bookworm)
Machine:
  Type: Desktop Mobo: GIGABYTE model: MZBSWAP-00 v: 1.x
    serial: <superuser required> UEFI: American Megatrends v: F5
    date: 03/23/2016
CPU:
  Info: dual core model: Intel Celeron N3000 bits: 64 type: MCP arch: Airmont
    rev: 3 cache: L1: 112 KiB L2: 2 MiB
  Speed (MHz): avg: 964 high: 1068 min/max: 480/2080 cores: 1: 860 2: 1068
    bogomips: 4160
  Flags: ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx
    Integrated Graphics vendor: Gigabyte driver: i915 v: kernel arch: Gen-8
    bus-ID: 00:02.0
  Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X:
    loaded: modesetting unloaded: fbdev,vesa dri: crocus gpu: i915
    resolution: 1280x1024~60Hz
  API: OpenGL v: 4.6 Mesa 22.3.6 renderer: Mesa Intel HD Graphics 400 (BSW)
    direct-render: Yes
Audio:
  Device-1: Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series
    High Definition Audio vendor: Gigabyte driver: snd_hda_intel v: kernel
    bus-ID: 00:1b.0
  API: ALSA v: k6.1.0-17-amd64 status: kernel-api
  Server-1: PipeWire v: 0.3.65 status: active
  Server-2: PulseAudio v: 16.1 status: off (using pipewire-pulse)
Network:
  Device-1: Intel Wireless 3160 driver: iwlwifi v: kernel bus-ID: 02:00.0
  IF: wls1 state: down mac: <filter>
  Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    vendor: Gigabyte driver: r8169 v: kernel port: e000 bus-ID: 03:00.0
  IF: enp3s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Bluetooth:
  Device-1: Intel Bluetooth wireless interface type: USB driver: btusb v: 0.8
    bus-ID: 1-5:5
  Report: hciconfig ID: hci0 rfk-id: 0 state: up address: <filter> bt-v: 2.1
    lmp-v: 4.0
Drives:
  Local Storage: total: 111.79 GiB used: 16.36 GiB (14.6%)
  ID-1: /dev/sda vendor: Kingston model: SUV400S37120G size: 111.79 GiB
Partition:
  ID-1: / size: 27.33 GiB used: 7.62 GiB (27.9%) fs: ext4 dev: /dev/sda2
  ID-2: /boot/efi size: 511 MiB used: 15.9 MiB (3.1%) fs: vfat
    dev: /dev/sda1
  ID-3: /home size: 80.55 GiB used: 8.52 GiB (10.6%) fs: ext4 dev: /dev/sda4
Swap:
  ID-1: swap-1 type: partition size: 977 MiB used: 202.8 MiB (20.8%)
    dev: /dev/sda3
Sensors:
  System Temperatures: cpu: 64.0 C mobo: N/A
  Fan Speeds (RPM): N/A
Info:
  Processes: 176 Uptime: 10h 51m Memory: 3.75 GiB used: 2.83 GiB (75.4%)
  Init: systemd target: graphical (5) Compilers: gcc: 12.2.0 Packages: 1822
  Shell: Bash v: 5.2.15 inxi: 3.3.26

[FreewheelinFrank]

I have edited the post as you requested. I hope it is now alright.

The machine is a barebones system, running 24/7, always logged in.

System info as follows.

Thank you. it's good now.

From the information you have given, I can't see why the machine would be sleeping down, unless it is something to do with the remote access process itself - something I'm not familiar with.

Maybe there is a hardware specific bug? I will have a look later on when I have time.

The Debian Wiki does give a couple of methods of preventing suspend. You could try those - hopefully they will override what ever is causing the machine to sleep.

https://wiki.debian.org/Suspend#Systemd_timeouts

[humphrey]

If I remember correctly, it started after I upgraded from Debian 11 to 12.

[CwF]

Ask for xset settings

Code: Select all

$  xset -q
...skip to the end
DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Enabled
  Monitor is On

this one will blank in 5 minutes
to never blank:

Code: Select all

$ xset s 0 0 & xset dpms 0 0 0

...I think

[FreewheelinFrank]

Ask for xset settings

Code: Select all

$  xset -q
...skip to the end
DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Enabled
  Monitor is On

this one will blank in 5 minutes
to never blank:

Code: Select all

$ xset s 0 0 & xset dpms 0 0 0

...I think

I had a look at DPMS, but the suspend setting seems to apply old CRT monitors. DPMS is short for Display Power Management Signaling. Can it also put the computer to sleep?

[FreewheelinFrank]

System logs might say something about why the system is sleeping.

Code: Select all

# journalctl -b --no-pager > /tmp/suspend.log

(or -b -1 for previous session.)

There's a lot of output, so use pastebin facility.

https://www.baeldung.com/linux/journalctl-check-logs

Edit: corrected format.

[CwF]

Can it also put the computer to sleep?

No, I would check it since a blank screen is similar to sleeping! Without any DE power management installed X will still blank by default. In case all the methods are somehow confused in any particular setup and not responding, the background xset, usually ignored or inactive, may be set.
Even VM's blank without any crt's anywhere.

[FreewheelinFrank]

Can it also put the computer to sleep?

No, I would check it since a blank screen is similar to sleeping! Without any DE power management installed X will still blank by default. In case all the methods are somehow confused in any particular setup and not responding, the background xset, usually ignored or inactive, may be set.
Even VM's blank without any crt's anywhere.

My thinking was, the three DPMS commands have specific meaning for CRT monitors: turn the gun off, turn the tube off, and turn the monitor off, so even if one is called "suspend", it's anachronistic as with flat screen displays, as they are all interpreted as "turn the LEDs off", or blank the screen. This is not the same to me as sleep, where other devices are turned off. Empirically, this means my display takes a fraction of a second to come back to life after the screen blanks, but several seconds after it has gone into suspend, and I can hear the hard disk spinning up.

But that is just the way I was thinking. You are right to point out that a blank screen is similar to sleep. I should have established what the OP meant by sleep. To be honest I have never used a remote system, and have no idea what screen blanking and suspend would imply when using one.

I totally agree that it's worth trying the xset setting. My perspective could be completely wrong. Thanks for pointing that out, even if it's a "doh!" moment for me if it fixes the issue.

If that doesn't work, the journalctl output should confirm if the computer is actually suspending.

[humphrey]

$ xset -q

Code: Select all

[...]
Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  0    cycle:  0
[...]
DPMS (Energy Star):
  Standby: 0    Suspend: 0    Off: 0
  DPMS is Enabled
  Monitor is On

$ sudo journalctl -b --no-pager > suspend.log
see pastebin app.php/pastebin/?mode=view&s=96

$ sudo journalctl -b -1 --no-pager > suspend.log
see pastebin app.php/pastebin/?mode=view&s=95

[Lew_Rockwell_Fan]

If you don't come up with a proper solution that works soon, FWIW, I had a similar issue in another distro and finally just did something inelegant to "solve" it: I wrote a script with a dash shebang auto started at login to run in the background with an endless loop that used xdotool to minimally jiggle the pointer (that arrow most people now insist on calling "mouse cursor") every 10 seconds. 1 pixel left, then 1 pixel right was sufficient. That's not enough to interfere with normal usage. Worked for me. YMMV.

[humphrey]

xdotool works well. Thank you.

But I would still prefer a proper solution.

FWIIW xdotool has no effect when running in a virtual machine.

[humphrey]

I did my homework and examined the two logs that I posted, but I couldn't find any string 'suspend'.
I gather that means that the system did not actually suspend.
Now I understand even less of what is happening.
Any suggestion?

And how should I now rephrase the title?