You are not logged in.
Hi everyone.
I use a secondary HDD for backups. It's plugged to my computer permanently but actually it is needed for a few seconds per day. A backup script automatically shuts it down after backing up with `hdparm -Y` to save a power and reduce a noise. And I want to shut down an HDD also every time after the system is started.
I tryed two ways to implement this.
1. Udev rule that runs `hdparm -Y` for the device identified by ID_SERIAL_SHORT attribute.
2. Following systemd service:
[Unit]
Description=Put HDD to sleep mode immediately
After=systemd-udev-trigger.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/hdparm -Y /dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1HL210777
[Install]
WantedBy=sysinit.target
Both methods actually run hdparm, but state of the HDD is active after login (I check it with hdparm -C). It looks like something in systemd "touches" the hard drive and wakes it up back. And I can't find what may access the secondary HDD after udev rules are processed.
What is correct way to solve the issue?
Thanks.
Last edited by dimich (2013-05-03 02:32:38)
Offline
Obviously something must be polling for it after the command is given. Maybe if the command is issued later, it might stick for longer. I presume that those two way which you mentioned do it during boot, after which the normal boot process polls for additional devices.
What if you use the systemd.timer function to wait a while before calling your example service above. There is a systemd.timer man page, as well as a systemd.time page to tell you about how to denote time in a unit.
Offline
Yes, it works with systemd timer. It even works if I just call `sleep 10' before hdparm. It's suitable as workaround, and I guess there should be cuter solution to "run something when everything are initialized".
Offline
Well, I think you would need to determine everything that might be polling your drives during the boot process, which might be a pretty big task. Then use that information to determine either when udev should run that command, and use the lexicographically ordered rules to try finding just the right spot (and even then it might just come down to a race). Or you can use the gathered info to try and make systemd's service dependencies do the work for you. Either way, I would honestly rather just use a timer.
Offline
Well, I solved the issue just by switching to "WantedBy=basic.target" and removing "After=systemd-udev-trigger.service".
Thank you for your attention.
Offline
Fantastico!
Please mark the thread as [Solved] by editing the first post (which will allow you to edit the title).
Offline