web-dev-qa-db-ja.com

systemdからudevルールをトリガーする

私は非常に積極的な電源管理を備えたそれらのHDDの1つを持っています。ロードサイクルがクリティカル数に上昇するのを防ぐために、udevルールを作成しました。

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

問題は、ノートブックをスリープから復帰させた後、このルールがトリガーされないことです。したがって、私は次のsystemdサービスを持っています：

[Unit]
Description=root resume actions
After=suspend.target

[Service]
Type=simple
ExecStart=/bin/hdparm -B 200 /dev/sda

[Install]
WantedBy=suspend.target

ExecStartコマンドは/bin/udevadm trigger --subsystem-match="block"のようなものにしたいと思います。したがって、カーネル名を明示的に記述する必要はありません。このコマンドを手動で実行すると、電力管理は正しく調整されますが、systemdサービスからは機能しません。これを行う方法はありますか？ところで私はArch-linuxを使用しています

arch-linuxudevsystemd
7
MoFu

Hdparmを実行するスクリプトを/usr/lib/systemd/systemd-sleepに置くことができます。また、/dev/disk/by-uuid/の代わりに/dev/sda...を指定してhdparmを使用できます。

または、/bin/sh -c "/bin/hdparm -B 200 /dev/disk/by-uuid/XY"を使用してみてください

2
AlphaBeta

私はほぼ同じ状況にあり、Googleでsystemd udevadm triggerが目立つため、またこれらのドライブの不条理なデフォルトを飼いならす方法の全体的な要約として、この質問にさらに情報を追加したいと思います。

Western Digital Blueドライブがひいきになり、逆効果で、反SMARTヘルス、パワー-無駄ナンセンスがデフォルトで有効になっていることに気付いたら、OPとほぼ同じプロセスに従いました。ファームウェア機能を無効にしましたが、hdparmを使用してAPMとスタンバイを無効にする必要がありました。 3つすべてがなければ、横行するロードサイクリングは暴走し続けました。

最初の違いは、私のhdparm.rulesはデバイスの追加のみ（ブート）で呼び出すように設定されているため、udevadm triggerは、指定しない限り機能しないということですwhichトリガーを適用します、--action=addを追加します。これにより、再開時にHDのプラグを抜く/再接続することが効果的にシミュレートされます。これはまさに私が必要としていることです。

しかし、OPと同様の混乱が生じ、udevadm triggerをリロードするためのhdparm ruleがターミナルで機能したが、systemd serviceからは機能しなかった理由を理解できませんでした。私にはさまざまな理由があったようです。

  1. serviceでは、ユニットファイルがExecStart /bin/udevadmを認識しないため、実行可能ファイルの場所を$pathに明示的に指定する必要があります。
  2. そして多分 ....私はそれをsystemd/userにインストールしましたが、それは私として実行された可能性があり、したがって/sbin/hdparmに必要なroot権限を取得していません。

（私はDebian 8を実行していますが、これがディストリビューション固有のものであるとは思いません。）

1
underscore_d