Wie man eine udev-Regel debuggt (in /etc/udev/rules.d/…)

15

Ich erstelle eine neue Grundregel

/etc/udev/rules.d/10-myrule.rules

enthält:

KERNEL!="sdb*", GOTO="auto_mount_end"
ACTION=="add", RUN+="/usr/bin/mount /dev/sdb1 /media"
LABEL="auto_mount_end"

Ich habe eine SD-Karte gespeichert, neu gestartet und eingelegt (erkannt durch /dev/sdb1, ich sehe es mit dmesg), aber nichts passiert. Wenn ich es manuell mache mount /dev/sdb1 /media, funktioniert es.

Wie kann ich eine solche udevRegel beheben / debuggen ?

Hinweis: Ich verwende ArchLinux, aber es sollte auf jeder Distribution gleich sein.

arch-linux mount udev

— Basj
quelle

1

Ändern Sie den Dateinamen in 99-myrule.rules...

— jasonwryan

@ jasonwryan: das gleiche: nichts passiert. Wie behebe ich eine udev-Regel? Sollte ich es manuell auslösen (wie in diesem Fall?)

— 4.

Ändert systemdsich etwas am normalen Verhalten von udev?

— Basj

1

Versuchen Sie udevadm monitor, dies und das zu sehen

— Aquarius Power

1

Bei AFAIK muss man nicht neu starten, um udev zum erneuten Lesen der Regeln zu bewegen (siehe unix.stackexchange.com/a/39371/44760 ). Ich habe mein udev-Debugging (was in der Tat nicht die einfachste Aufgabe ist!) Mit durchgeführt udevadm testund Regeln gegen die Realität mit validiert udevadm info.

— Zagrimsan

11

10-wie von jasonwryan erwähnt, benutze eine hohe nummerierung (90er gut). Ihre Regel wird also nicht von einer anderen außer Kraft gesetzt.
Verwenden Sie die Mindestanzahl von Schlüsseln so, wie Sie sie wirklich benötigen. Beispiel, !=& GOTO/ LABEL, stattdessen direkt verwenden==
```
ACTION=="add", KERNEL=="sdb*", RUN+="/usr/bin/mount /dev/sdb1 /media"
```
Ihr Ziel war sdb1mit festem Befehl, minimieren Sie die blinde Übereinstimmung mitKERNEL=="sdb1"
Ich finde es nützlich, eine Shadow-Debugging-Regel zu erstellen. Ich habe Shadow genannt, weil ich sie immer in derselben Datei belasse, also benutze ich sie, wenn ich sie brauche.
```
ACTION=="add", KERNEL=="sdb*", RUN+="/bin/sh -c 'echo == >> /home/user/Desktop/udev-env.txt; env >> /home/user/Desktop/udev-env.txt'"
#ACTION=="add", KERNEL=="sdb*", RUN+="/usr/bin/mount /dev/sdb1 /media"
```
Hinweis: udev-env.txt Wird erstellt, wird die Regel trotzdem ausgelöst. Zeile==, die einem passenden Knoten entspricht. Die in dieser Datei aufgezeichnete ENV kann eine Mischung aus zwei oder mehr Knoten sein, die fast gleichzeitig erstellt werden. Dies ist einstdoutPufferproblem.
Verwendung udevadm monitor -u, udevadm test ...und udevadm trigger ... um zu überprüfen , welche Regeln die Ereignisse verarbeitet.
Innerhalb der Skripte können Sie das Debug-Protokoll erstellen und fehlgeschlagene Befehle abfangen, indem Sie deren Rückgabewert stdoutund stderrNachrichten speichern .

Aktualisieren:

Referenz: udev_237 - man udev (Ubuntu_18.04)

RUN{type}

Note that running programs that access the network or mount/unmount filesystems is not
allowed inside of udev rules, due to the default sandbox that is enforced on
systemd-udevd.service.

— user.dz
quelle

1

Sehr hilfreich. In einigen Kommentaren werden udevadm test...nur die Umgebungsvariablen angezeigt, damit ATTRSSie udevadm info $DEVICEdiese anderen Einstellungen finden können.

— Att Righ

1

Bei der udevadm infoRückgabe eines Gerätebaums ist darauf zu achten, dass die Einstellungen zwischen einem Gerät und seinen übergeordneten Geräten unterschieden werden (Eigenschaften scheinen vererbt zu werden, wenn sie nicht überschrieben werden). In meinem Fall war das Subsystem falsch.

— Att Righ

udevadm test "This program is for debugging only, it does not run any program specified by a RUN key. It may show incorrect results, because some values may be different, or not available at a simulation run."

Kann man nicht einfach nachvollziehen, was tatsächlich passiert?

— MarcH

@MarcH, können Sie verwenden udevadm monitor -u, um nach Ereignissen / Bedingungen udevadm trigger ...zu suchen und deren Aktionen zu testen.

— user.dz

@MarcH, aber innerhalb der Skripte liegt es an Ihnen, das Debug-Protokoll zu erstellen und fehlgeschlagene Befehle abzufangen (indem Sie deren Rückgabewert speichern, auch stdout & stderr-Meldungen).

— user.dz

1

Ich denke, der Befehl, den Sie hier suchen, ist udevadm. Sie verwenden die Parameter triggerund test, um einen erneuten Scan der udev-Ereignisse auszulösen bzw. ein bestimmtes Ereignis zu testen.

Ich habe das auf die harte Tour gelernt, als ich mit dem neuen Netzwerkgerätenamen in EL 7 herumgebastelt habe. Viel Glück!

— Paul
quelle

1

Erstellen Sie eine udev-Regeldatei

sudo nano /etc/udev/rules.d/99-removable-sd.rules

Fügen Sie eine Regel hinzu, die die Udisks anweist, sie automatisch zu aktivieren
```
SUBSYSTEM=="block", SUBSYSTEMS=="mmc", DRIVERS=="mmcblk", ATTRS{type}=="SD", ENV{UDISKS_AUTO}="1", ENV{UDISKS_SYSTEM}="0"
```
ATTRS{type}=="SD" ist möglicherweise nicht erforderlich, wenn Sie verschiedene Typen verwenden.
Regeln neu laden
```
sudo udevadm control -R
```
Wirf es aus und lege es zurück.

Verweis: Archlinux Wiki: Einige Geräte, die als entfernbar behandelt werden sollten, sind dies nicht

— user.dz
quelle

0

Ich hatte das gleiche Problem mit RASPBERRY PI 3 B +, möglicherweise helfen Ihnen die oben genannten Befehle. Aber es hat mir NICHT geholfen. Ich habe versucht, ein Skript zum Einfügen eines USB-Speichergeräts aufzurufen. Die Regeln werden nicht in Syslog protokolliert, sodass es sehr schwierig wird zu verstehen, welche Regel funktioniert hat oder welche Regel fehlgeschlagen ist.

Also habe ich folgendes gemacht:

(1) Ich habe meine Regeldatei in /etc/udev/rules.d/100-myrule.rules erstellt

(2) Dann habe ich den Befehl ausgeführt sudo /etc/init.d/udev restart

dann habe ich nachgesehen, ob es funktioniert hat. Eine Information kann für Sie nützlich sein oder auch nicht, aber die Dateisysteme sind nur für udev lesbar, bis der Befehl unter (2) ausgeführt wird.

— MSharq
quelle