7

I have one of those hdds, that have a very aggressive power management. To prevent load cycles from rising in to critical numbers I wrote an udev rule: 

SUBSYSTEM=="block", SUBSYSTEMS=="scsi", ATTRS{model}=="TOSHIBA MK2555GS", RUN+="/usr/bin/hdparm -B 200 /dev/%k"

The problem is, that this rule is not triggered aftr i wake my notebook from sleep. Therefore i have the following systemd service:

[Unit] Description=root resume actions After=suspend.target [Service] Type=simple ExecStart=/bin/hdparm -B 200 /dev/sda [Install] WantedBy=suspend.target

I'd prefer the ExecStart command to be something like /bin/udevadm trigger --subsystem-match="block". So I don't have to state the kernel name explicitly. If I do this command manually the power managment is adjusted correctly but it doesn't work from the systemd service. Is there a way to do this? btw I'm using arch-linux

Improve this question

2 Answers 2

Reset to default
2

You could put a script in /usr/lib/systemd/systemd-sleep which execute hdparm. And you can use hdparm with /dev/disk/by-uuid/ instead of /dev/sda...

Or try to use /bin/sh -c "/bin/hdparm -B 200 /dev/disk/by-uuid/XY"

Improve this answer
1
  • In the end I used ExecStart= /bin/bash -c "/bin/udevadm trigger --subsystem-match='block'" Commented Nov 29, 2013 at 20:35
1

I was in nearly the same situation and would like to add more information to this question due to its prominence on Google for systemd udevadm trigger and as an overall summary of how to tame the absurd defaults in these drives.

Once I realised my Western Digital Blue drive has patronising, counterproductive, anti-SMART-health, power-wasting nonsense enabled by default, I followed nearly the same process as the OP. I disabled the firmware feature but additionally needed to disable APM and standby using hdparm; without all 3, the rampant load-cycling continued to run amok.

The first difference is that, because my hdparm.rules were set to invoke on device add only (boot), udevadm trigger would not work for me unless I told it which trigger to apply, by adding --action=add. This effectively simulate un-/re-plugging of the HD on resume - which is exactly what I need.

But I ended up with similar confusion to the OP, unable to figure out why my udevadm trigger to reload my hdparm rule worked in the terminal but not from a systemd service. It seems that I had different reasons, which were:

  1. In our service, we must explicitly specify the location of the executable to ExecStart /bin/udevadm because unit files are not aware of $path;
  2. and maybe.... I had it installed in systemd/user, which may have run as me and thus not gotten the root permissions needed for /sbin/hdparm.

(I run Debian 8, but I don't believe any of this is distro-specific.)

Improve this answer
1
  • 1
    fwiw, I have since stopped using udev for this, moving to a systemd service triggered by boot and after all suspend-type actions, which invokes hdparm for me. This way I can manage it all in one place - systemd - rather than requiring a udev boot rule and a systemd resume service. Commented Oct 9, 2015 at 12:14

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.