Wie udev Regeln ohne Neustart neu zu laden?

209

Wie sollte man udev-Regeln neu laden, damit neu erstellte funktionieren können?

Ich verwende Arch Linux und habe hier keinen udevstartBefehl.

Auch geprüft /etc/rc.d, kein udev-Service da.

kernel udev

— Gänseblümchen
quelle

1

Bitte beachten Sie, dass neuere Versionen von udev die Unterstützung für inotify eingestellt haben, so dass das Neuladen der Änderungsregeln heutzutage häufiger erforderlich ist.

— Colin Guthrie

Was ist udev? Ist es der Manager von /dev?

— Sandburg

1

@ Sandburg Ja, es funktioniert Plug-n-Play auf Linux-Systemen.

— Aaron D. Marasco

229

# udevadm control --reload-rules && udevadm trigger

— Ignacio Vazquez-Abrams
quelle

4

Brauchst du udevtriggerdanach

— Nils

38

@Nils Tatsächlich benötigen Sie möglicherweise udevtrigger(oder besser gesagt udevadm triggerbei den meisten Distributionen) stattdessen (das, oder stecken Sie das Gerät aus und wieder ein). --reload-rulesist fast immer nutzlos, da es automatisch passiert.

— Gilles

12

udevadm triggerhabe den Trick auf CentOS 6 für mich gemacht.

— Astrostl

3

udevtriggeroder udevadm triggerhat bei mir nicht funktioniert. Ich habe festgestellt, dass einige Geräte nach dem Entladen und Laden des Moduls für dasselbe funktionieren (vorausgesetzt, es ist ein ladbares Modul). Was ich herausgefunden habe ist, dass man das System nicht unbedingt neu starten muss. Beispiel für ein Netzwerkgerät, ich rmmod ixgbe, rmmod tg3, rmmod e1000dann modprobe ixgbe, modprobe tg3, modprobe e1000je nach Art des Netzwerktreiber.

— enthusiasticgeek

1

Keines der in den Antworten genannten Dinge funktionierte für mich bei Debian Jessie (8.0). Die Sache, die funktioniert hat, ip link set $oldname name $newnamewird hier erwähnt . In meinem Fall musste ich ein iface namens landurch ein überbrücktes iface (für KVM) ersetzen , und daher musste das ursprüngliche - jetzt zugrunde liegende - iface seinen alten Namen eth1zurückbekommen. Der Trick war also: 1) iface runter bringen; 2) Netzwerkkonfiguration reparieren; 3) udev-Benennungsregeldatei aktualisieren; 4) benenne das iface um mit ip link...; 5) Bringe die Brücke hoch.

— Kostix

69

Udev verwendet den Inotify- Mechanismus, um nach Änderungen im Regelverzeichnis sowohl in der Bibliothek als auch in den lokalen Konfigurationsbäumen (normalerweise in /lib/udev/rules.dund /etc/udev/rules.d) zu suchen. Die meiste Zeit müssen Sie also nichts tun, wenn Sie eine Regeldatei ändern.

Sie müssen den udev-Daemon nur explizit benachrichtigen, wenn Sie etwas Ungewöhnliches tun, z. B. wenn Sie eine Regel haben, die Dateien in einem anderen Verzeichnis enthält. Dann können Sie die gewohnte Konvention verwenden, um Daemons aufzufordern, ihre Konfiguration neu zu laden: Senden Sie ein SIGHUP ( pkill -HUP udevd). Oder Sie können die Verwendung udevadmBefehl: udevadm control --reload-rules.

Beachten Sie jedoch, dass verschiedene Versionen von udev in der Vergangenheit unterschiedliche Auslöser für das automatische Neuladen der Regeln hatten. Also, wenn Sie Zweifel haben, rufen Sie an udevadm control --reload-rules: Es schadet sowieso nicht.

Die udev-Regeln werden nur angewendet, wenn ein Gerät hinzugefügt wird. Wenn Sie die Regeln erneut auf ein bereits verbundenes Gerät anwenden möchten, müssen Sie dies explizit tun, indem Sie udevadm triggermit den richtigen Optionen aufrufen, die den Geräten entsprechen, deren Konfiguration sich geändert hat, z udevadm trigger --attr-match=vendor='Yoyodyne' --attr-match=model='Frobnicator 300'.

— Gilles
quelle

1

Verwendet systemd udev inotify, um auf Regeländerungen zu achten?

— Craig McQueen

Der inotifyMechanismus erfasst nicht immer eine Änderung einer udev-Regeldatei. Wenn ich zum Beispiel cat > 10-name.rulesdie Regeldatei durch Einfügen des Inhalts ändere, muss ich die Regeln manuell mit neu laden udevadm. Getestet auf Raspbian Stretch.

— Daniel K.

@ DanielK. Hat sich das kürzlich geändert? IIRC Ich habe sowohl systemd udev als auch non-systemd udev überprüft, als ich diese Antwort gepostet habe, und beide haben inotify verwendet, --reload-ruleswas nur in seltenen Fällen erforderlich war.

— Gilles

@ Gilles: Vielleicht kann mein Beispiel oben (Überschreiben einer vorhandenen Regeldatei mithilfe der Shell-Umleitung) als "ungewöhnlicher Fall" angesehen werden. Als ich diese Datei über einen Editor, z. B. vi, modifizierte, inotifyfunktionierte der Mechanismus.

— Daniel K.

@ DanielK. Ah, das ist gut zu wissen. Es kommt nicht selten vor, dass einige Redakteure die Datei durch Umschreiben speichern (bei Vim und Emacs hängt es davon ab, wie sie konfiguriert sind). Seltsam, dass udev nur einen der Fälle behandelt - es sieht für mich nach einem Fehler aus, weil ich mir keinen Grund vorstellen kann, sie anders zu behandeln.

— Gilles

19

Ich füge dies hinzu, weil ich es eines Tages wieder brauchen werde.

Manchmal erhalten Sie eine falsche Zuordnung von Ethernet-Gerätenummern und MAC-Adressen. Dies ist manchmal sehr wichtig, beispielsweise wenn in einer VM ausgeführt wird und jedes Gerät einem anderen VLAN zugewiesen ist.

Fahren Sie dann die Netzwerkschnittstellen herunter
ändern /etc/udev/rules.d/70-persistent-net.rules(oder gleichwertig)
neu laden mit udevadm control --reload-rules
erneut auslösen mit udevadm trigger --attr-match=subsystem=net
Rufen Sie die Netzwerkschnittstellen auf.

Ich war überrascht, wie gut das funktioniert hat.

— Otheus
quelle

6

auf Red Hat:

service network stop && udevadm control --reload-rules; udevadm trigger --attr-match=subsystem=net; service network start

— Alexander Torstling

1

Unter Debian funktioniert der 'udevadm-Trigger --attr-match = subsystem = net' nicht. Ich musste erst die USB-Ethernet-Karte aus- und einstecken, dann löste udev eine neue Regel aus.

— Trismegistos

Ich würde wetten, Trismegistos, dass das Entfernen / Stecken mit dem Entfernen und Neuladen des Netzwerktreibers vergleichbar ist, wie Clayton Dukes antwortete.

— Mike S

12

Ich bin nicht sicher, ob dies zutrifft, und dies ist definitiv ein älterer Beitrag, aber meine Websuche nach udev-Informationen war ziemlich umfangreich, sodass ich dachte, ich könnte etwas Wissen teilen.

Sie können udev-Regeln für bestimmte Geräte manuell auslösen. Dies gilt nur für Redhat-bezogene Distributionen (Centos Fedora usw. usw. usw.).

Sobald Sie die relevanten Änderungen in Ihrer Regeldatei ( /etc/udev/rules.d/whateveryoucalledyourrules) vorgenommen haben, können Sie changedas Ereignis des Geräts erneut anzeigen.

echo change > /sys/block/devname/partname1/uevent

Dies erzwingt eine udev-Regel, die NUR für dieses Gerät gelesen wird. Viel besser und meiner Meinung nach gezielter.

— mbadmin
quelle

4

Für mich hat die folgende Befehlssequenz wie gewünscht funktioniert.

Ich habe Änderungen vorgenommen /etc/udev/rules.d/70-persistent-net.rules, um die ethNummer zu ändern und sie ohne Neustart neu zu laden.

/etc/init.d/networking stop
/etc/init.d/udev stop
udevadm control --reload-rules
/etc/init.d/udev start
/etc/init.d/networking start

Auf diese Weise wurde es zur Laufzeit erfolgreich geladen, ohne dass der Computer neu gestartet werden musste.

Vorschläge oder Empfehlungen dazu sind willkommen, da ich dies selbst durch Lesen der Manpages entdeckt habe.

— Aditya Malviya
quelle

2

Ich füge hier die richtige Antwort hinzu, da ich eine Weile gebraucht habe, um sie im Kommentar von @enthusiasticgeek zu bemerken. Alles, was Sie tun müssen (vorausgesetzt, Sie befinden sich auf der Konsole des Servers - dies ist offensichtlich schlecht, wenn Sie sich im SSH-Modus befinden!):

Rufen Sie eine Liste der verwendeten Schnittstellenmodule ab:

cat /etc/udev/rules.d/70-persistent-net.rules | grep "PCI device" | perl -pe 's/.*$(\w+)$.*/$1/g'| uniq

In meinem Fall ist es igbso, dass es genau das druckt.

Typ sudo rmmod igb(Ersetzen Sie ihn igbdurch Ihren Kartentreiber aus Schritt 1.

Bearbeiten Sie /etc/udev/rules.d/70-persistent-net.rulesdas Modul nach Bedarf und laden Sie es dann erneut mit modprobe igb. Ersetzen Sie es erneut durch igbIhr Modul .

— Clayton Dukes
quelle

Zusammen mit der Antwort von Otheus war dies die geheime Sauce, die es mir ermöglichte, die Konfiguration meiner Mellanox-Netzwerkkarte ohne Neustart des Computers zu reparieren. Ich glaube, dass das Laden des Treibers und das Lesen von udevadm der Datei persistent-net.rules in etwa dem entspricht, was das System beim Booten tut.

— Mike S

0

im Falle mehrerer Netzwerke

cat /etc/udev/rules.d/70-persistent-net.rules | grep "PCI device" | awk '{print $NF}'|sed -e 's/(//g' -e 's/)//g'| uniq > /tmp/listnet
rm -rf /etc/udev/rules.d/70-persistent-net.rules 
for i in $(cat /tmp/listnet); do rmmod $i; modprobe $i;done
service network restart
rm -rf /tmp/listnet

— alex tmp
quelle