When restart from suspend or hibernate not work

[WonderSkydive]

If we suspend the computer or hibernate, when it resumes, hd-idle no longer works. It only works when we start the computer or restart, if we suspend or hibernate it, when it resumes, it no longer works. After much reading, I saw that this happens because the hd-idle counter, I do not remember now exactly, does not count well when we wake up the computer to sleep or hibernate. We need created a new systemd-unit that restarts the hd-idle service, / etc / systemd / system / and must be activated with the command: systemctl enable hd-idle-restart-resume.service The content of the file: [Unit] Description=Restart hd-idle After=suspend.target After=hibernate.target After=hybrid-sleep.target

[Service] Type=simple ExecStart=/bin/systemctl --no-block restart hd-idle

[Install] WantedBy=suspend.target WantedBy=hibernate.target WantedBy=hybrid-sleep.target

Thanks and regards.

[adelolmo]

Hi @WonderSkydive

What version of hd-idle are you running? I thought this issue was fixed by now.

[WonderSkydive]

Hi @adelolmo ! Sorry for the delay in replying, I've had some intense days...

I am currently using version 1.16 downloaded from here and deb packaged as indicated (I was unaware of this version here, a fellow forum member informed me of it).

In dependencies comes 1.05a, so I uninstalled 1.05a and installed this one, 1.16.

According to my tests, what was mentioned kept happening, so I had to add the patch so that it did not happen. It is not a "clean" installation of version 1.16 but I did purge 1.05a, but I had to remove the patch "by hand".

Any other information that is required, tests or everything necessary, at your disposal.

Thank you very much for your comment/response.

[auanasgheps]

Hi @adelolmo I can confirm the issue is back.

I can see this issue appearing again on Debian 11, whilst Debian 10 was rock solid.

It does not occur all the time, but today I noticed my disks weren't spinning down and I was able to do some checks. I can confirm the process has died after resuming from sleep:

root@nas:/# service hd-idle status
hd-idle.service - hd-idle - spin down idle hard disks
     Loaded: loaded (/lib/systemd/system/hd-idle.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Wed 2022-06-29 18:48:48 CEST; 8min ago
       Docs: man:hd-idle(8)
    Process: 1112 ExecStart=/usr/sbin/hd-idle $HD_IDLE_OPTS (code=killed, signal=TERM)
   Main PID: 1112 (code=killed, signal=TERM)
        CPU: 704ms

Let me know if you need more information.

[adelolmo]

Hi @auanasgheps Thank you for the details.

I've created a pre release that might solve the issue. Could you please try it out?

[auanasgheps]

Thanks for the fast response @adelolmo! I installed the 1.17 pre release version. Please give me a couple of days so I can be sure, because the issue does not always appear.

[WonderSkydive]

Like @auanasgheps, thanks @adelolmo for this response.

Also, I installed the 1.17, I try in the next days.

Regards.

[auanasgheps]

It's working... but also not.

Today I've done the real first test with version 1.17, and:

• the service has not died, but service hd-idle status shows a timestamp from the server boot and not the server resume from suspend, is this correct? Active: active (running) since Sun 2022-07-03 11:30:37 CEST; 12h ago
• hd-idle has been spinning down all drives after suspend... except one. Which is NOT used because it's my parity SnapRAID drive and NOTHING accesses it other than my daily snapraid routine. And that drive has been spinning since the server resumed from sleep :( The same drive was spundown before the sleep.

[WonderSkydive]

In my case, it still doesn't work after computer sleep, the service is still running but... no hard disk spindown, none. This is before suspending:

wonder@PC-wonder:~$ systemctl status hd-idle ● hd-idle.service - hd-idle - spin down idle hard disks Loaded: loaded (/lib/systemd/system/hd-idle.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2022-07-03 23:35:16 CEST; 2min 6s ago Docs: man:hd-idle(8) Main PID: 995 (hd-idle) Tasks: 4 (limit: 18969) Memory: 4.7M CPU: 8ms CGroup: /system.slice/hd-idle.service └─995 /usr/sbin/hd-idle -i 0 -a sda -i 90 -a sdb -i 90 -a sdc -i 90

jul 03 23:35:16 PC-wonder systemd[1]: Started hd-idle - spin down idle hard disks. jul 03 23:35:16 PC-wonder hd-idle[995]: symlinkPolicy=0, defaultIdle=0, defaultCommand=scsi, debug=false, logFile=, devices={name=sda, giv> jul 03 23:36:55 PC-wonder hd-idle[995]: sda spindown jul 03 23:36:55 PC-wonder hd-idle[995]: sdb spindown jul 03 23:36:55 PC-wonder hd-idle[995]: sdc spindown

wonder@PC-wonder:~$ sudo hdparm -C /dev/sdc

/dev/sdc: drive state is: standby wonder@PC-wonder:~$ sudo hdparm -C /dev/sdb

/dev/sdb: drive state is: standby wonder@PC-wonder:~$ sudo hdparm -C /dev/sda

/dev/sda: drive state is: standby

And this, after suspending overnight, then resuming for 20 minutes, then suspending again and resuming:

wonder@PC-wonder:~$ systemctl status hd-idle ● hd-idle.service - hd-idle - spin down idle hard disks Loaded: loaded (/lib/systemd/system/hd-idle.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2022-07-03 23:35:16 CEST; 8h ago Docs: man:hd-idle(8) Main PID: 995 (hd-idle) Tasks: 9 (limit: 18969) Memory: 6.1M CPU: 114ms CGroup: /system.slice/hd-idle.service └─995 /usr/sbin/hd-idle -i 0 -a sda -i 90 -a sdb -i 90 -a sdc -i 90

jul 03 23:35:16 PC-wonder hd-idle[995]: symlinkPolicy=0, defaultIdle=0, defaultCommand=scsi, debug=false, logFile=, devices={name=sda, giv> jul 03 23:36:55 PC-wonder hd-idle[995]: sda spindown jul 03 23:36:55 PC-wonder hd-idle[995]: sdb spindown jul 03 23:36:55 PC-wonder hd-idle[995]: sdc spindown jul 04 07:41:07 PC-wonder hd-idle[995]: sdc spinup jul 04 07:47:16 PC-wonder hd-idle[995]: sdc spindown jul 04 07:50:08 PC-wonder hd-idle[995]: sda spinup jul 04 07:50:08 PC-wonder hd-idle[995]: sdc spinup jul 04 07:51:47 PC-wonder hd-idle[995]: sda spindown jul 04 07:51:56 PC-wonder hd-idle[995]: sdc spindown

But...:

wonder@PC-wonder:~$ sudo hdparm -C /dev/sda

/dev/sda: drive state is: active/idle wonder@PC-wonder:~$ sudo hdparm -C /dev/sdb

/dev/sdb: drive state is: active/idle wonder@PC-wonder:~$ sudo hdparm -C /dev/sdc

/dev/sdc: drive state is: active/idle

The hard drivers are up...

[auanasgheps]

I have experienced your case in the past days: service is up and no disks are spun-down, even if I know they are not used. Alternatively, just 1 or 2 disks are spun-down but the others are "forgotten"

[WonderSkydive]

Correct, that happens to me, with all (there are 3 that I have configured). As I read at the time, it refers to the time account, once the equipment is suspended and resumed, the time account is no longer correct, said account is not restarted (I say it from memory, I don't know exactly).

[auanasgheps]

What do you mean for "time account"?

[WonderSkydive]

I'll see if I can find the link where I could read about this problem, that's why using hd-idle-restart-resume.service "fixes" it or at least patches it.

I mean hd-idle counter, it has the "timer" to know when it has to spindown, apparently, when we sleep pc, we hibernate... when we resume, this "timer" fails and that's why this happens issue.

I found the patch at the time here: https://sourceforge.net/p/hd-idle/patches/2/

I hope it helps.

[adelolmo]

@WonderSkydive I also spotted that patch and applied it in early versions: https://github.com/adelolmo/hd-idle/pull/3/files The thing is that I never had a chance to test it.

Given the story you both are telling, I'm guessing my re-implementation is buggy. I'll have to dig down the rabbit hole and see what I find in the bottom.

Thank you for you input!

[auanasgheps]

For what is worth, your hd-idle rewrite has been a dream for a very long time on Debian 10 (OpenMediaVault 5), which was going in standby every day. Never had an issue. This issue appears on Debian 11 (OMV6), so I don't know if the OS has made some changes that make hd-idle broken after standby.

[WonderSkydive]

@adelolmo Thanks to you for your work, when I discovered your site with updated hd-idle code, heaven opened for me, then I knew it has a sequel...

From what I read, I knew you had changed code and corrected that "problem" but it has never worked for me.

The colleague @auanasgheps indicates that it has always worked for him until Debian 10, the problem comes from Debian 11.

In my case I have always used it on systems based on ubuntu, specifically in recent years on kubuntu, I have always had the same problem, although it is true that, in your latest versions, the service does not disappear (but it does not spindown the hard drives after to resume pc).

This happens to me, the service now does not die or disappear, fine, but after resuming the "counter" it seems to not work well and does not spindown.

The rabbit hole is usually a place where there is everything, if I can help with something, I'm happy about it.

[adelolmo]

I did some testing with 1.17 and I cannot reproduce the behavior that you got. Could you please have a look to https://github.com/adelolmo/hd-idle/issues/59#issuecomment-940886016 ? I just want to narrow what the possible root cause is.

[auanasgheps]

udisks2 is not installed on my system.

[cbxd82]

Hello, thank you for your work.

This is to confirm that this issue also occurs on my computer.

My computer suspends to RAM after an hour with my disks spun down. After I wake it up, my disks (without activity) spins again and will not spin back down after 10 minutes as configured. The only way for it to spin the disks down is to restart the systemd service after each resume from suspend.

For information, I use Archlinux with systemd 251.4-1 and hd-idle 1.18-1

Best wishes, Christophe

[adelolmo]

Summary (for my own sanity):

1. The service did not resume after suspension/hibernation
2. This issue got fix in v1.17
3. Then the service is resume after suspesion/hiberbation, but disks don't spin down anymore (unless some activity creates read/write disk activity)

Since #81 covers already the last open issue, I'd like to move the conversation there and close this issue.