Come eseguire il debug di una regola udev (in /etc/udev/rules.d/…)

15

Sto creando una nuova regola di base

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

contenente:

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

Ho salvato, riavviato e inserito una scheda SD (riconosciuta da /dev/sdb1, la vedo con dmesg), ma non succede nulla. Quando lo faccio manualmente mount /dev/sdb1 /media, funziona.

Come posso risolvere / eseguire il debug di tale udevregola?

Nota: sto usando ArchLinux, ma dovrebbe essere lo stesso su qualsiasi distribuzione?

arch-linux mount udev

— Basj
fonte

1

Cambia il nome del file in 99-myrule.rules...

— jasonwryan

@jasonwryan: lo stesso: non succede nulla. Come risolvere una regola udev? Devo

— attivarlo

Fa systemdcambiare qualcosa per il comportamento normale udev?

— Basj,

1

prova udevadm monitor, guarda questo e questo

— Aquarius Power,

1

AFAIK non è necessario riavviare per far sì che udev rileggi le regole (consultare unix.stackexchange.com/a/39371/44760 ). Ho eseguito il debug di udev (che in effetti non è il compito più semplice!) Con udevadm teste convalidato le regole contro la realtà con udevadm info.

— Zagrimsan,

11

10-come menzionato da Jasonwryan, usa una numerazione elevata (buona 90). Quindi la tua regola non sarà annullata da un'altra.
Usa le chiavi minime proprio come hai veramente bisogno. Esempio, !=& GOTO/ LABEL, invece utilizzare direttamente==
```
ACTION=="add", KERNEL=="sdb*", RUN+="/usr/bin/mount /dev/sdb1 /media"
```
Il tuo obiettivo era sdb1con comando fisso, minimizza la partita cieca usandoKERNEL=="sdb1"
Trovo utile creare una regola di debug shadow, ho chiamato shadow perché lo lascio sempre lì nello stesso file, quindi lo uso quando ne ho bisogno.
```
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"
```
Nota: udev-env.txt viene creato, quindi la regola viene attivata comunque. Linea==corrispondente a un nodo corrispondente. L'ENV registrato in quel file potrebbe essere un misto tra 2 o più nodi, creato quasi nello stesso momento, è unstdoutproblema di buffering.
Uso udevadm monitor -u, udevadm test ...e udevadm trigger ... di verificare le regole elaborati gli eventi.
All'interno degli script spetta a te fare il log di debug e catturare i comandi non riusciti, salvando anche il loro valore di ritorno stdoute i stderrmessaggi.

Aggiornare:

Riferimento: 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
fonte

1

Molto utile. Un paio di commenti udevadm test...sembrano mostrare solo le variabili di ambiente, per ottenere ATTRSpuoi usare udevadm info $DEVICEper trovare queste altre impostazioni.

— Att Righ,

1

In udevadm inforitorni un albero di dispositivi fare attenzione a distinguere le impostazioni tra un dispositivo e i suoi dispositivi padre (le proprietà sembrano essere ereditate se non sovrascritte). Nel mio caso il sottosistema era sbagliato.

— 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."

Non c'è modo di rintracciare ciò che sta realmente accadendo?

— MarcH

@MarcH, è possibile utilizzare udevadm monitor -uper verificare eventi / condizioni e udevadm trigger ...per testare le loro azioni.

— user.dz

@MarcH, ma all'interno degli script spetta a te fare il log di debug e catturare i comandi non riusciti (salvando il loro valore di ritorno anche i messaggi stdout e stderr).

— user.dz

1

Penso che il comando che stai cercando qui sia udevadm. Utilizzerai i parametri triggere testper attivare una nuova scansione degli eventi udev e testare un evento specifico, rispettivamente.

L'ho imparato nel modo più duro quando mi sono lasciato andare con la nuova denominazione dei dispositivi di rete in EL 7. Buona fortuna!

— Paolo
fonte

1

Crea un file di regole udev

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

Aggiungi la regola che dice a udisks di montarlo automaticamente
```
SUBSYSTEM=="block", SUBSYSTEMS=="mmc", DRIVERS=="mmcblk", ATTRS{type}=="SD", ENV{UDISKS_AUTO}="1", ENV{UDISKS_SYSTEM}="0"
```
ATTRS{type}=="SD" potrebbe non essere necessario se si utilizzano tipi diversi.
Ricarica le regole
```
sudo udevadm control -R
```
Espellilo e poi rimettilo.

Riferimento: Archlinux Wiki: Alcuni dispositivi, che dovrebbero essere trattati come rimovibili, non lo sono

— user.dz
fonte

0

Avevo lo stesso problema con RASPBERRY PI 3 B +, potrebbe essere possibile che i comandi sopra ti possano aiutare. Ma NON mi ha aiutato. Stavo cercando di invocare uno script durante l'inserimento di un dispositivo di archiviazione USB. Le regole non vengono registrate in syslog, quindi diventa molto difficile capire quale regola ha funzionato o quale regola non è riuscita.

Quindi ho fatto quanto segue:

(1) Ho creato il mio file delle regole in /etc/udev/rules.d/100-myrule.rules

(2) quindi ho eseguito il comando sudo /etc/init.d/udev restart

poi ho controllato che funzionasse. Un'informazione può essere utile o no, ma i filesystem sono di sola lettura per udev fino a quando non viene eseguito il comando in (2).

— MSharq
fonte