udev-Regeln von systemd auslösen

7

Ich habe eine dieser Festplatten, die ein sehr aggressives Power-Management haben. Um zu verhindern, dass Lastzyklen auf kritische Zahlen ansteigen, habe ich eine udev-Regel geschrieben:

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

Das Problem ist, dass diese Regel nicht ausgelöst wird, nachdem ich mein Notebook aus dem Ruhezustand geweckt habe. Daher habe ich den folgenden systemd Service:

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

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

[Install]
WantedBy=suspend.target

Ich würde es vorziehen ExecStart, wenn der Befehl so etwas wie wäre /bin/udevadm trigger --subsystem-match="block". Ich muss den Kernelnamen also nicht explizit angeben. Wenn ich diesen Befehl manuell ausführe, wird das Energiemanagement korrekt angepasst, funktioniert jedoch nicht über den systemd-Dienst. Gibt es eine Möglichkeit, dies zu tun? Übrigens benutze ich Arch-Linux

arch-linux udev systemd

— MoFu
quelle

2

Sie könnten ein Skript /usr/lib/systemd/systemd-sleepeinfügen, in dem hdparm ausgeführt wird. Und Sie können hdparm mit /dev/disk/by-uuid/anstelle von verwenden/dev/sda...

Oder versuchen Sie es zu verwenden /bin/sh -c "/bin/hdparm -B 200 /dev/disk/by-uuid/XY"

— Alpha Beta
quelle

Am Ende habe ichExecStart= /bin/bash -c "/bin/udevadm trigger --subsystem-match='block'"

— MoFu

1

Ich befand mich in fast derselben Situation und möchte dieser Frage aufgrund ihrer Bedeutung bei Google für systemd udevadm triggerund als allgemeine Zusammenfassung, wie die absurden Standardeinstellungen in diesen Laufwerken gezähmt werden können , weitere Informationen hinzufügen .

Sobald ich meine Western Digital Blue Laufwerk erkannt hat gönnerhaft, kontraproduktiv , anti-SMART-Gesundheit, kraftraub aktiviert Unsinn standardmäßig folgte ich fast den gleichen Prozess wie der OP. Ich habe die Firmware-Funktion deaktiviert, musste aber zusätzlich APM und Standby mit deaktivieren hdparm. ohne alle 3 lief der zügellose Lastzyklus weiter Amok.

Der erste Unterschied besteht darin, dass, da ich hdparm.rulesso eingestellt war, dass nur auf dem Gerät Add (Boot) aufgerufen wird, udevadm triggerdies für mich nicht funktioniert, wenn ich nicht durch Hinzufügen angegeben habe, welcher Trigger angewendet werden soll --action=add. Dies simuliert effektiv das Ent- / Wiedereinstecken der Festplatte bei Wiederaufnahme - genau das, was ich brauche.

Aber ich hatte eine ähnliche Verwirrung wie das OP und konnte nicht herausfinden, warum ich udevadm triggermeine hdparm ruleArbeit im Terminal neu laden sollte, aber nicht von einem systemd service. Es scheint, dass ich verschiedene Gründe hatte, die waren:

In unserem serviceFall müssen wir den Speicherort der ausführbaren Datei explizit angeben, ExecStart /bin/udevadmda die Einheitendateien nicht bekannt sind $path.
und vielleicht ... ich hatte es installiert systemd/user, das möglicherweise als ich ausgeführt wurde und daher nicht die rooterforderlichen Berechtigungen erhalten hat /sbin/hdparm.

(Ich verwende Debian 8, aber ich glaube nicht, dass dies distro-spezifisch ist.)

— underscore_d
quelle

1

fwiw, ich habe seitdem aufgehört, udevdies zu verwenden, und bin zu einem systemdDienst übergegangen, der durch Booten und nach allen Aktionen vom Typ Suspend ausgelöst wurde, die hdparmfür mich aufgerufen werden . Auf diese Weise kann ich alles an einem Ort verwalten - systemdanstatt eine udevStartregel und einen systemdWiederaufnahme-Service zu benötigen .

— underscore_d