Вы могли вставить сценарий /usr/lib/systemd/systemd-sleep
которые выполняют hdparm. И можно использовать hdparm с /dev/disk/by-uuid/
вместо /dev/sda...
Или попытайтесь использовать /bin/sh -c "/bin/hdparm -B 200 /dev/disk/by-uuid/XY"
Я был почти в такой же ситуации и хотел бы добавить больше информации к этому вопросу из-за его популярности в Google для systemd udevadm trigger
и как общее резюме того, как приручить абсурдные настройки по умолчанию в этих дисках.
Как только я понял, что на моем диске Western Digital Blue по умолчанию включена покровительственная, контрпродуктивная, анти-SMART-health, энерго-расточительная ерунда, я выполнил почти тот же процесс, что и ОП. Я отключил функцию прошивки, но дополнительно потребовалось отключить APM и режим ожидания с помощью hdparm
; без всех трех функций безудержная циклическая нагрузка продолжала работать.
Первое отличие в том, что, поскольку мои hdparm.rules
были настроены на вызов только при добавлении устройства (boot), udevadm trigger
не сработал бы для меня, если бы я не указал ему какой триггер применить, добавив --action=add
. Это эффективно имитирует отсоединение/подсоединение HD при возобновлении работы - именно то, что мне нужно.
Но в итоге я оказался в таком же замешательстве, как и ОП, не в состоянии понять, почему мой udevadm trigger
для перезагрузки моего hdparm rule
сработал в терминале, но не от systemd service
. Похоже, у меня были разные причины, а именно:
службе
мы должны явно указать расположение исполняемого файла для ExecStart /bin/udevadm
, потому что юнит-файлы не знают о $path
;systemd/user
, который мог работать от моего имени и, таким образом, не получить root
разрешения, необходимые для /sbin/hdparm
. (Я использую Debian 8, но я не думаю, что это зависит от дистрибутива)
.
ExecStart= /bin/bash -c "/bin/udevadm trigger --subsystem-match='block'"
– MoFu 29.11.2013, 22:35