After upgrading Ubuntu on my desktop computer from 24.04 to 26.04, it became very slow to wake up after being put to sleep: in 24.04 it came up almost instantly (apart from wired network, which has always been slow), but in 26.04 it took long enough that my displays (which I usually power off after suspending the computer) decided there was no signal coming, and went to sleep. In all, it now took almost a minute from my pressing a key till GDM’s login screen came up.
My first suspicion was that something had changed in Systemd’s sleep hooks (under /lib/systemd/system-sleep/), but there weren’t any obvious culprits. I had one of my own scripts there (to turn the annoying LEDs on an external USB hub on and off), and although it’s not fast, it’s not that slow either. Still, I eliminated it by removing it temporarily, which had no effect.
The only other possible culprit was a script from hdparm (/lib/systemd/system-sleep/hdparm):
#!/bin/sh
case $1 in
post)
/usr/lib/pm-utils/power.d/95hdparm-apm resume
;;
esacI added a couple of echo lines to it, one above and one below the call to 95hdparm-apm resume, and this (or rather, viewing journalctl‘s output after the next suspend+resume) revealed that it took 17 seconds for it to complete. I have a couple of hard disk drives that have always been sluggish to spin up, and apparently Systemd now no longer considers the wakeup done until the script is finished. (This script was there already back in 24.04, and the current hdparm package in 26.04 is only a no-change rebuild of the same version that is in 24.04, so the script content also hasn’t changed.)
I moved /lib/systemd/system-sleep/hdparm temporarily elsewhere, and that restored the almost instantaneous wakeup.
hdparm -B for the drives after this wakeup showed that they’re using APM level 164 by default. Journal logs from before disabling the hdparm script showed that the script sets the APM level to 254 for both drives.
164 is above what hdparm‘s man page documents as allowing spin-down (1—127), but ChatGPT distilled the rest as “the 128–254 range controls things such as how aggressively the drive may enter other power-saving states, head parking, interface power management, etc. The higher the number, the more aggressively the drive is biased toward performance and away from power saving.”
Of these, besides performance, I mostly care about things that may affect the drives’ longevity, such as head parking. So I’m now monitoring smartctl‘s view into their Load_Cycle_Count to see if they do excessive parking at the default level. If they do, or if the performance hit from the lower level turns out to be too much, I’ll have to reinstate the hdparm script and find a workaround for it holding the wakeup hostage.