Cómo depurar una regla udev (en /etc/udev/rules.d/…)

15

Estoy creando una nueva regla básica

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

que contiene:

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

Guardé, reinicié e inserté una tarjeta SD (reconocida por /dev/sdb1, lo veo con dmesg), pero no sucede nada. Cuando lo hago manualmente mount /dev/sdb1 /media, funciona.

¿Cómo puedo solucionar / depurar dicha udevregla?

Nota: Estoy usando ArchLinux, pero ¿debería ser igual en cualquier distribución?

arch-linux mount udev

— Basj
fuente

1

Cambie el nombre del archivo a 99-myrule.rules...

— jasonwryan

@jasonwryan: lo mismo: no pasa nada. ¿Cómo solucionar problemas de una regla de udev? ¿Debo activarlo manualmente (¿cómo en este caso?)

— Basj

¿ systemdCambia algo el comportamiento normal de udev?

— Basj

1

intenta udevadm monitor, mira esto y esto

— Aquarius Power

1

AFAIK one no necesita reiniciar para que udev vuelva a leer las reglas (consulte unix.stackexchange.com/a/39371/44760 ). He realizado mi depuración de udev (¡que de hecho no es la tarea más fácil!) Y he udevadm testvalidado las reglas contra la realidad con udevadm info.

— zagrimsan

11

10-como lo mencionó jasonwryan, use una numeración alta (buena para los 90). Así que tu regla no será anulada por otra.
Use las teclas mínimas tal como realmente necesita. Ejemplo, !=& GOTO/ LABEL, en lugar de usar directamente==
```
ACTION=="add", KERNEL=="sdb*", RUN+="/usr/bin/mount /dev/sdb1 /media"
```
Su objetivo era sdb1con un comando fijo, minimice la coincidencia ciega usandoKERNEL=="sdb1"
Me resulta útil crear una regla de depuración de sombra, llamé a shadow porque siempre la dejo allí en el mismo archivo, así que la uso cuando la necesito.
```
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 se crea y la regla se activa de todos modos. Línea==correspondiente a un nodo coincidente. El ENV registrado en ese archivo podría ser una mezcla entre 2 nodos o más, creado casi al mismo tiempo, es unstdoutproblema de almacenamientoenbúfer.
Uso udevadm monitor -u, udevadm test ...y udevadm trigger ... para verificar qué reglas procesan los eventos.
Dentro de los scripts, depende de usted hacer el registro de depuración y capturar comandos fallidos, guardando también el valor de retorno stdouty los stderrmensajes.

Actualizar:

Referencia: 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
fuente

1

Muy útil. udevadm test...Parece que un par de comentarios solo le muestran variables de entorno, ATTRSque puede usar udevadm info $DEVICEpara encontrar estas otras configuraciones.

— Att Righ

1

En los udevadm inforetornos, un árbol de dispositivos debe tener cuidado de distinguir la configuración entre un dispositivo y sus dispositivos principales (las propiedades parecen heredarse si no se anulan). En mi caso, el subsistema estaba mal.

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

¿No hay forma de rastrear lo que realmente está sucediendo?

— MarcH

@MarcH, puede usar udevadm monitor -upara verificar eventos / condiciones y udevadm trigger ...probar sus acciones.

— user.dz

@MarcH, pero dentro de los scripts depende de usted hacer el registro de depuración y capturar los comandos fallidos (al guardar su valor de retorno también los mensajes stdout y stderr).

— user.dz

1

Creo que el comando que estás buscando aquí es udevadm. Utilizará los parámetros triggery testpara activar un nuevo análisis de los eventos udev y para probar un evento específico, respectivamente.

Aprendí esto de la manera difícil cuando busqué con el nuevo nombre de dispositivo de red en EL 7. ¡Buena suerte!

— Pablo
fuente

1

Crear un archivo de reglas de udev

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

Agregue una regla que le indique a los udiscos que lo monten automáticamente
```
SUBSYSTEM=="block", SUBSYSTEMS=="mmc", DRIVERS=="mmcblk", ATTRS{type}=="SD", ENV{UDISKS_AUTO}="1", ENV{UDISKS_SYSTEM}="0"
```
ATTRS{type}=="SD" puede no ser necesario si está utilizando diferentes tipos.
Reglas de recarga
```
sudo udevadm control -R
```
Expulsar y luego volver a poner.

Referencia: Archlinux Wiki: algunos dispositivos, que deben tratarse como extraíbles, no son

— user.dz
fuente

0

Estaba teniendo el mismo problema con FRAMBUESA PI 3 B +, podría ser posible que los comandos anteriores puedan ayudarlo. Pero no me ayudó. Intenté invocar un script al insertar un dispositivo de almacenamiento USB. Las reglas no se registran en syslog, por lo que resulta muy difícil entender qué regla funcionó o qué falló.

Entonces hice lo siguiente:

(1) Hice mi archivo de reglas en /etc/udev/rules.d/100-myrule.rules

(2) luego ejecuté el comando sudo /etc/init.d/udev restart

Luego verifiqué que funcionó. Una información puede ser útil para usted o no, pero los sistemas de archivos son de solo lectura para udev hasta que se ejecute el comando en (2).

— MSharq
fuente