Powering off the hard drives at shutdown

[Marus780]

Hi !

I want to power off the hard drives connected to my Raspberry Pi after the shutdown sequence is completed and before I cut the power to the system.

To poweroff I use the command `udisksctl power-off -b /dev/sda`.

To execute the python script that gives that command at shutdown, I do like this:
- I create the folder `systemd-poweroff.service.d` in `/etc/systemd/system'
- I create the file ShutdownScript.conf inside it
- I add to the file:
[Service]
ExecStartPre=python3 /home/marus/ups_script.py shutdown

The problem is that when the script is executed I get the error:
`Error connecting to the udisks daemon: Could not connect: Connection refused`.
And I think that this piece of software that I called to poweroff the drives is already terminated at shutdown...

How can I solve this ? Is there a way to start again that daemon, do the job and then close it from my script, or can I use another software to power off the hard drives ?

[swampdog]

Big question is why?

There'll be something in the 'poweroff' command on a PC linux which does something very late on the kernel shutdown which causes a PC motherboard to kill power but even that isn't going to work for usb attached peripherals. The linux kernel attempts to unmount all filesystems: once that is done it's okay to kill the power thus you could cobble together some hardware to do the job.

Digressing for a moment. The problem on one of my rpi is it has some enclosures attached with spinning rust disks inside. Those disks keep going to sleep which is fine for one enclosure but not for the one I use as an NFS mountpoint. No sooner do they spin down, something will try to access the NFS filesystem whereupon they spin back up again. This is very bad for reliability. Consequently I have a cron job which "touches" a file every few minutes to prevent it. Once the rpi is off, the disks spin down about 5 minutes later.

Provided you don't need near instant poweroff this could be a solution for you. Use an enclosure which allows spinning rust disks to go to sleep plus a spinning rust disk which can go to sleep. This can be a bit tricky with usb. You don't have the full control of a sata interface. I have one disk which will spin down but refuses to spin back up. When (eventually) I figured this out, it went into the enclosure I "touch".

Another idea is what I use for my inaccessible rpi. One of those cheapo manual remote controls which come with pack of mains wireless sockets. I type the usual "sudo poweroff" and once the monitor says "no signal" I click the button on the remote which kills its power.

[thagrol]

Self powered or bus powered drives?

Flash or HDD?

Do your drives honour the commands being sent to them? Does the controller/bridge IC still remain powered?

Posting the contents of /home/marus/ups_script.py will likely help us help you.

You could try setting apropriate dependencies in your service file so that it runs after unmounts but before the udisks daemon is stopped. No, I don't know what those dependencies are.

An alternative option for bus powered drives would be to switch off power to the USB ports during the shutdown process. Google uhubctl for one tool to do that.

Self powered drives can be more complex. Your best option is both to turn off the USB port power and to use some external hardware to turn off the external power. Obviously you'll need code in your boot strap to turn that back on.

Be aware that the above two suggestions are just that and are untested.

Though I have to ask why you want to do this. I don't do this on any of my Pi with USB connected bus powered drives or any of my PCs and have never had a problem. 11 years with pi (yes I started with the original rev of the 1B) and several decades with PCs.

[Marus780]

I have a hardware circuit which cuts the power supply of the whole system after my script is done. The HDDs are self powered from the same supply. I know it is safe to cut the power after the shutdown sequence is done (which unmount the drives), but I don't like the sound that they make when they ar spinning and the power is suddenly switched off...

In the file `/home/marus/ups_script.py` I have this (just the code relevant for this task):

Code: Select all

import RPi.GPIO as GPIO
import socket
import time
import sys
import signal
import threading
import subprocess
import psutil

def PowerOffHDD():
  disks = [disk for disk in psutil.disk_io_counters(perdisk=True) if "sd" in disk and not disk[-1].isdigit()]
  devices = ''
  for disk in disks: devices = devices + '/' + disk
  AllOK = True
  ErrorMsg = ''
  for disk in disks:
    cmd = ['hdparm', '-Y', '/dev/'+disk]
    result = subprocess.run(cmd, capture_output=True)
    if result.returncode != 0:
      AllOK = False
      ErrorMsg = ErrorMsg + result.stderr.decode()
  if AllOK == True: SendMessage(HPMSG+'('+devices+')\n')
  else: SendMessage(ErrorMsg)

if len(sys.argv) > 1:
  if sys.argv[1] == 'shutdown':
    PowerOffHDD()
    SendMessage(SDMSG)
  elif sys.argv[1] == 'reboot': SendMessage(RBMSG)
  else: print("Invalid argument. Use 'reboot' or 'shutdown'.")
  sys.exit(0)

This script is executed after the system has completed the shutdown sequence and is ready to signal to the control board to cut the power. And that will happen when my script exits.

In this code I changed the command that put the HDDs in sleep mode to `hdparm -Y /dev/xxx` and it seems it's working. But I'm not sure what's going on there, 'cause I can't see nothing at that point. When the HDDs are running and I press the shutdown button I hear when they are spinning off one by one and the the power is cut. But if they are already in sleep mode, the system wake them up (perhaps to flush the buffers or something) and then it's a mess...

[swampdog]

Re-read my post. I think you missed something. The best you can hope for, is usb drives might read/write mounted file systems correctly. Almost all usb interfaces are cheap tat which can vary in the same production run. You can even purchase multiple items at the same time and find they behave differently.

[redvli]

In this code I changed the command that put the HDDs in sleep mode to `hdparm -Y /dev/xxx` and it seems it's working. But I'm not sure what's going on there, 'cause I can't see nothing at that point. When the HDDs are running and I press the shutdown button I hear when they are spinning off one by one and the the power is cut. But if they are already in sleep mode, the system wake them up (perhaps to flush the buffers or something) and then it's a mess...

You can write whatever code, but you don't know what is in the HDD's firmware. My experience is that you can't be sure that if you have it somehow working a with 1 model/brand HDD, that is also works the same way with another one. That is with x86 boards with direct SATA. Same for ARMv7 boards. And then in addition you have an USB controller in between that throws its methods into the game.

If you don't like the sound, put them away where you can't hear them, that was and is always my 'workaround'.

[Marus780]

Guys, I really don't understand what you are talking about... Are you worried that the sleep commands don't arrive at the HDD controler ? I did some tests in which I gave the Sleep command separately to each individual HDD and it stopped spinning. So the commands reach the HDD...

[Marus780]

I finally made it !
The key was to wake up all the hard drives (I use `hdpar -g /dev/xxx`) and then put them all to sleep and cut the power. But you must give some time after each operation so that the drive can spinn up and down. Cutting the power in the middle of those operations is not good !

Code: Select all

def PowerOffHDD():
  disks = [disk for disk in psutil.disk_io_counters(perdisk=True) if 'sd' in disk and not disk[-1].isdigit()]
  devices = '/'.join(disks); AllOK = True;
  if devices == '': return

  for disk in disks:
    cmd = ['hdparm', '-g', '/dev/'+disk]
    result = subprocess.run(cmd, capture_output=True, text=True)
    if AllOK and result.returncode != 0:
      AllOK = False
      ErrorMsg = f'Error while waking up device /{disk}...\n'+result.stderr
  time.sleep(6)

  for disk in disks:
    cmd = ['hdparm', '-Y', '/dev/'+disk]
    result = subprocess.run(cmd, capture_output=True, text=True)
    if AllOK and result.returncode != 0:
      AllOK = False
      ErrorMsg = f'Error while powering off device /{disk}...\n'+result.stderr

  if AllOK: ResMsg = HPMSG+' ('+devices+')'
  else: ResMsg = ErrorMsg
  SendMessage(ResMsg)
  time.sleep(6)

[thagrol]

It's your system so it's your choice but spinning up a spun down HDD just to spin it down again seems less than ideal: unnecessary wear and tear on the HDD and your PSU has to deal with the inrush current again.

If you PSU isn't up to snuff that in rush current could cause more problems that your approach solves.

[Marus780]

Could you please tell me in what way the HDD is weared off if it is turned ON and OFF ? I heard that a lot, but nobody explains why ?
The inrush current is not so big, so that it can affect the motor winding in any way.

The thing is that, even without this, the Raspberry would wake up some of the HDDs when I give the shutdown command. Maybe to write cache or somethin... But after that, it suddenly cut the power and it's possible that some HDD get caugh in the middle of spinning up or down, which is verry bad. With my method this process si done in a much more controlled and safe way.

[thagrol]

Spindle bearings. More head park/unpark operations = more opportunty for a head crash.

[Marus780]

This operation will happen very rarely. How often do you think you need to shut down a server that has a UPS ? Probably only when you change the battery... A hard drive can withstand 600,000 Load/Unload cycless so I wouldn't worry about that.

[ejolson]

Spindle bearings. More head park/unpark operations = more opportunty for a head crash.

From what I understand, a factor in HD longevity is constant temperature. The actual temperature--within reason--is not as important as it being constant.

Powering up and down a drive causes changes in temperature as does using them without adequate ventilation.

From a practical point of view, the main question is whether one saves enough on energy consumption to make up for the higher failure rate.

For a resource limited individual a non-optimal solution may be preferred due to keeping the NAS in the same room where one sleeps at night or for which noise is a greater concern. Powering off at night also makes sense when solar panels or batteries are involved.

From a save the planet point of view, the energy costs of running an old drive needs to be offset against the costs of manufacturing new ones. For example, a government program to buy, destroy and replace less efficient automobiles that are seldom driven by newer more efficient models may consume more energy in the end as well as disrupt the circular economy of used cars which is necessary for people with less income to be self supporting. The point is that if the car is seldom used, the cost of manufacturing a new car is greater compared to the cost of operating the existing but less efficient one.

In my opinion, the greatest benefit of electric vehicles will likely come from moving sources of pollution outside of densely populated cities, especially given what sources of energy are used to generate the electricity and how much energy is lost by conventional power grids, but that's getting off topic.

Back on topic, a spinning drive will consume 3 to 10W while a typical PC consumes much more at idle. Thus, turning off a PC is more likely to be green and cost effective compared to powering down the drives on a Pi-based NAS that is used daily. On the other hand, I can see a benefit if the drives stay off longer than 24 hours.