триггер udev правил от systemd

У меня есть один из тех hdds, которые имеют очень агрессивное управление питанием. Чтобы предотвратить увеличение циклов загрузки до критических чисел, я написал правило udev:

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

Проблема в том, что это правило не вызвано aftr, я разбужу свой ноутбук от сна. Поэтому у меня есть следующая служба systemd:

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

Я бы предпочел, ExecStart команда ExecStart была чем-то вроде /bin/udevadm trigger --subsystem-match="block" . Поэтому я не должен указывать имя ядра явно. Если я сделаю эту команду вручную, управление питанием будет настроено правильно, но оно не будет работать из службы systemd. Есть ли способ сделать это? btw Я использую arch-linux

2 Solutions collect form web for “триггер udev правил от systemd”

Вы можете поместить скрипт в /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"

Я был в почти такой же ситуации и хотел бы добавить дополнительную информацию к этому вопросу из-за его systemd udevadm trigger Google для systemd udevadm trigger и в качестве общего резюме того, как приручить абсурдные значения по умолчанию в этих дисках.

Как только я понял, что мой диск Western Digital Blue имеет покровительство, контрпродуктивную, анти-SMART-работоспособность, пустяковую бессмысленность, включенную по умолчанию, я следил за тем же процессом, что и OP. Я отключил функцию прошивки, но дополнительно необходимо отключить APM и режим ожидания с помощью hdparm ; без всех 3, безудержный цикл нагрузки продолжал работать.

Первое отличие состоит в том, что, поскольку мои hdparm.rules были настроены на hdparm.rules на устройстве add only (boot), udevadm trigger не работал бы для меня, если бы я не сказал, какой триггер применить, добавив --action=add . Это эффективно имитирует отказ / повторное включение HD в резюме – что именно то, что мне нужно.

Но я udevadm trigger с подобной путаницей с OP, не в силах понять, почему мой udevadm trigger для перезагрузки моего hdparm rule работал в терминале, но не из systemd service . Кажется, у меня были разные причины, которые были:

  1. В нашем service мы должны явно указать местоположение исполняемого файла ExecStart /bin/udevadm потому что файлы модулей не знают о $path ;
  2. и возможно …. Я установил его в systemd/user , который, возможно, работал как я, и, следовательно, не получил root разрешений, необходимых для /sbin/hdparm .

(Я запускаю Debian 8, но я не считаю, что это связано с дистрибутивом.)

  • UDEV присваивает ATTRS {variable} значение ENV {variable}
  • Автоматизация USB-накопителей на Debian
  • разрешение отклонено / dev / bus / usb /
  • Как добиться быстрого переключения пользователей с помощью нескольких графических адаптеров, предотвратить использование виртуального терминала?
  • Как установить скорость и дуплексную скорость Ethernet
  • / dev / tty * последовательные устройства находятся в группе «root» на секунду, прежде чем они переключаются на группу «dialout». Как заставить их начать в «дозвоне»?
  • Как заставить CUPS отображать USB-принтер как отключенный, когда он отключен?
  • Redhat 7.1 Udev Изменяет правила SYMLINK + И Имя
  • Удаление From start_udev
  • Как назначить драйвер USB для устройства
  • / dev / disk / lists, почему / dev / net / не перечисляет сетевые интерфейсы?
  • Linux и Unix - лучшая ОС в мире.