Ubuntu 22.04 - suspend then hibernate failed with result 'dependency'

Question

Recently the suspend-to-hibernate function stopped working reliably. It happens that my battery is drained, although it should have went into hibernation.

This is what

journalctl | grep suspend

shows:

Nov 26 05:09:15 XYZ kernel: PM: suspend entry (s2idle)
Nov 26 05:09:15 XYZ kernel: PM: suspend exit
Nov 26 05:09:15 XYZ systemd[1]: systemd-suspend-then-hibernate.service: Main process exited, code=exited, status=1/FAILURE
Nov 26 05:09:15 XYZ systemd[1]: systemd-suspend-then-hibernate.service: Failed with result 'exit-code'.
Nov 26 05:09:15 XYZ systemd[1]: suspend-then-hibernate.target: Job suspend-then-hibernate.target/start failed with result 'dependency'.
Nov 26 05:09:15 XYZ systemd[1]: systemd-suspend-then-hibernate.service: Consumed 2.151s CPU time.
Nov 26 05:09:15 XYZ ModemManager[1057]: <info>  [sleep-monitor-systemd] system is about to suspend
Nov 26 05:09:15 XYZ systemd-sleep[137140]: Entering sleep state 'suspend'...
Nov 26 05:09:15 XYZ kernel: PM: suspend entry (deep)
Nov 26 05:09:35 XYZ kernel: PM: suspend exit
Nov 26 05:09:35 XYZ kernel: PM: suspend entry (s2idle)

And this just happened in a cycle, until the battery was drained. So my understanding is, somehow there is a dependency, that prevents it from hibernation?

Performing suspend or hibernate via terminal works fine:

systemctl suspend
Nov 26 16:39:11 XYZ ModemManager[933]: <info>  [sleep-monitor-systemd] system is about to suspend
Nov 26 16:39:14 XYZ systemd-sleep[19184]: Entering sleep state 'suspend'...
Nov 26 16:39:14 XYZ kernel: PM: suspend entry (deep)
Nov 26 16:39:27 XYZ kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Nov 26 16:39:27 XYZ kernel: PM: suspend exit
Nov 26 16:39:27 XYZ systemd[1]: systemd-suspend.service: Deactivated successfully.
Nov 26 17:21:10 XYZ ModemManager[933]: <info>  [sleep-monitor-systemd] system is about to suspend
Nov 26 17:22:31 XYZ kernel: printk: Suspending console(s) (use no_console_suspend to debug)

Any ideas?

Update:

Seems I cut off the journalctl content at the wrong place. I did now the following:

1. perform sudo systemctl suspend, then save journalctl
2. perform sudo hibernate, then save journalctl
3. perform sudo suspend-then-hibernate, then save journalctl
4. close the lid (which should trigger suspend-then-hibernate), then save journalctl

This showed that #1-3 are working fine, while #4 fails. Here the relevant log part for #3:

Dez 12 20:52:05 XYZ systemd[1]: Starting Record successful boot for GRUB...
Dez 12 20:52:05 XYZ systemd[1]: Starting Suspend; Hibernate if not used for a period of time...
Dez 12 20:52:05 XYZ systemd-sleep[8780]: Entering sleep state 'suspend'...
Dez 12 20:52:05 XYZ kernel: PM: suspend entry (deep)
Dez 12 20:52:26 XYZ kernel: Filesystems sync: 0.006 seconds
Dez 12 20:52:26 XYZ kernel: Freezing user space processes
Dez 12 20:52:26 XYZ kernel: Freezing user space processes completed (elapsed 0.004 seconds)
Dez 12 20:52:26 XYZ kernel: OOM killer disabled.
Dez 12 20:52:26 XYZ kernel: Freezing remaining freezable tasks
Dez 12 20:52:26 XYZ kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)

and for #4:

Dez 12 21:19:10 XYZ systemd[1]: Starting Record successful boot for GRUB...
Dez 12 21:19:10 XYZ systemd[1]: Starting Suspend; Hibernate if not used for a period of time...
Dez 12 21:19:10 XYZ systemd-sleep[19771]: Entering sleep state 'suspend'...
Dez 12 21:19:10 XYZ kernel: PM: suspend entry (deep)
Dez 12 21:19:10 XYZ kernel: Filesystems sync: 0.033 seconds
Dez 12 21:19:30 XYZ kernel: Freezing user space processes
Dez 12 21:19:30 XYZ kernel: Freezing user space processes failed after 20.007 seconds (1 tasks refusing to freeze, wq_busy=0):
Dez 12 21:19:30 XYZ kernel: task:modprobe        state:D stack:0     pid:19662 ppid:1948   flags:0x00004006
Dez 12 21:19:30 XYZ kernel: Call Trace:

And this behaviour just repeats itself, until the battery is drained. Searching for modprobe did not give any clarity to this. Any ideas?

Update 2:

Think I've found the issue.. I often have to restart pulseaudio (via pulseaudio -k && sudo alsa force-reload, from here), due to audio issues and seems this procedure is running in the background and blocking it then facepalm. A fast check of lid-closing with successful trigger of suspend-then-hibernate after a fresh restart confirmed this for now.

Answer 1

Don't post logvomit ("here's my guess at all the data - you figure it out").

Diagnostic procedure:

First step is to put a pin in the timestream with

date '+%y-%m-%d %H:%M:%S' >pin.tmp

Then, do your suspend/shutdown thing. When your system is usable again,

sudo journalctl  --since="$(cat pin.tmp)"

This will show you all the log messages since you set pin.tmp. Some messages relate to your problem.

Alternatively,

After the system comes up again, the terminal command sudo journalctl b -1 -ex will show the system logs leading up to the crash/shutdown. You can look at other shutdowns by varying the -b -1 option. If nothing stands out, suspect overheating or sudden power outage. Do sudo journalctl --list-boots, read man journalctl. For more journalctl help, see my AskUbuntu profile (click on my username).