Tracking down failure to wake from sleep

starting with systemd processes, i’ve found that i can use this command to get a list

sudo systemctl list-timers which produces this list

NEXT                             LEFT LAST                              PASSED UNIT                           ACTIVATES                       
Fri 2025-01-31 10:29:25 PST      7min Fri 2025-01-31 09:07:57 PST    47min ago fwupd-refresh.timer            fwupd-refresh.service
Fri 2025-01-31 10:30:00 PST      8min Fri 2025-01-31 10:21:24 PST      30s ago sysstat-collect.timer          sysstat-collect.service
Fri 2025-01-31 10:30:26 PST      8min Fri 2025-01-31 09:33:02 PST    22min ago anacron.timer                  anacron.service
Fri 2025-01-31 16:05:44 PST  5h 43min Fri 2025-01-31 09:08:00 PST    47min ago motd-news.timer                motd-news.service
Fri 2025-01-31 16:52:20 PST        6h Thu 2025-01-30 07:07:43 PST            - plocate-updatedb.timer         plocate-updatedb.service
Sat 2025-02-01 00:00:00 PST       13h Fri 2025-01-31 05:15:33 PST 2h 28min ago dpkg-db-backup.timer           dpkg-db-backup.service
Sat 2025-02-01 00:00:00 PST       13h -                                      - sysstat-rotate.timer           sysstat-rotate.service
Sat 2025-02-01 00:07:00 PST       13h -                                      - sysstat-summary.timer          sysstat-summary.service
Sat 2025-02-01 00:57:01 PST       14h Fri 2025-01-31 06:56:55 PST 2h 13min ago logrotate.timer                logrotate.service
Sat 2025-02-01 04:53:07 PST       18h Fri 2025-01-31 10:21:24 PST      30s ago apt-daily.timer                apt-daily.service
Sat 2025-02-01 06:04:42 PST       19h Fri 2025-01-31 07:31:42 PST 1h 38min ago apt-daily-upgrade.timer        apt-daily-upgrade.service
Sat 2025-02-01 07:58:29 PST       21h Fri 2025-01-31 05:20:33 PST 2h 23min ago update-notifier-download.timer update-notifier-download.service
Sat 2025-02-01 07:58:53 PST       21h Fri 2025-01-31 09:08:31 PST    47min ago man-db.timer                   man-db.service
Sat 2025-02-01 08:08:26 PST       21h Fri 2025-01-31 05:30:30 PST 2h 13min ago systemd-tmpfiles-clean.timer   systemd-tmpfiles-clean.service
Sun 2025-02-02 03:10:44 PST 1 day 16h Sun 2025-01-26 03:22:42 PST            - e2scrub_all.timer              e2scrub_all.service
Mon 2025-02-03 01:33:56 PST    2 days Mon 2025-01-27 07:21:10 PST            - fstrim.timer                   fstrim.service
Fri 2025-02-07 08:05:41 PST    6 days Sun 2025-01-26 20:18:03 PST            - update-notifier-motd.timer     update-notifier-motd.service

some of these are not showing that they “passed” and i’m particularly interested in the one’s that run in the middle of the nite, since that’s when my system locks up hard for some reason.

can anyone shed any light on which of these might be crashing my system?

How do you know it’s one of these?

Any hints from the logs? The last thing there ought to give you a hint. I figure you’ve probably already checked that… but if any of these started, that would be in the journal before they did anything that could have caused a freeze.

If the journal isn’t surviving, there are options for journald to write directly to non-volatile storage so it won’t have that problem. Could help?

no, i’m now suspecting it’s to do with ACPI from firmware since

/proc/acpi/wakeup

only shows S4 states and plasma says i can’t use hibernate so it only offers sleep or shutdown for suspend options (contradictory!)

i’m now learning how to write a bash script that will execute after a period of time instead, and will set the plasma suspend option to “do nothing”

i’m hoping if i do that the script will still be executed. [CONFIRMED]

1 Like

UPDATE: work around successful (at least during the day time)

UPDATE2: works at nite too… using systemctl suspend in the script and leaving int in the (S3) overnite produced no issues.

WORKAROUND:

set plasma power management to “do nothing” and instead after a period of time run a script to operate systemctl controls

systemctl requires the sudo privilege escalation but also requires a password, which is difficult and unwise to include in a bash script.

instead, used sudo visudo to add a line at the end of the file

[username] [pcname]=(ALL:ALL) NOPASSWD: /usr/bin/systemctl

which allows me [username] on my PC [pcname] to impersonate all users and all groups and to use systemctl without it asking for a password

you can check the settings were applied correctly by using sudo -ll

then i just made script in bash
heyy.sh

#!/bin/bash
sudo systemctl suspend-then-hibernate

note: it’s important for the script to be on your $PATH and set as executable…i created a ~/bin for scripts and kubuntu will automatically add that to the path for me when i log in.

and made sure the /etc/systemd/sleep.conf settings are correct for my hardware

AllowSuspend=yes
AllowHibernation=yes
AllowSuspendThenHibernate=yes
AllowHybridSleep=no
SuspendState=mem
HibernateState=disk
SuspendMode=suspend platform
HibernateMode=platform shutdown
MemorySleepMode=deep
HibernateDelaySec=2h
#SuspendEstimationSec=60min

and now my script will put the machine to sleep (suspend to RAM) and 2hrs later it will wake up momentarily to save everything to disk for the nite (S4).

the only variable left is will this actually work over nite since that seems to be the time it all goes tits up.

i would write a bug report detailing this but my previous bug report on plasma 6.1 was shot down due it not being “officially supported”, so it’s not fixed when 6.2 hits the development track then i will revisit.

1 Like