Comment déboguer une règle udev (dans /etc/udev/rules.d/…)

15

Je crée une nouvelle règle de base

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

contenant:

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

J'ai enregistré, redémarré et inséré une carte SD (reconnue par /dev/sdb1, je le vois avec dmesg), mais rien ne se passe. Quand je fais manuellement mount /dev/sdb1 /media, cela fonctionne.

Comment puis-je dépanner / déboguer une telle udevrègle?

Remarque: j'utilise ArchLinux, mais cela devrait être le même sur n'importe quelle distribution?

arch-linux mount udev Basj
la source
1
Changez le nom du fichier en 99-myrule.rules...
jasonwryan
@jasonwryan: pareil: il ne se passe rien. Comment dépanner une règle udev? Dois-je le déclencher manuellement (comment dans ce cas?)
Basj
systemdChange- t-il quelque chose au comportement normal d'udev?
Basj
1
essayez udevadm monitor, voyez ceci et cela
Aquarius Power
1
AFAIK one n'a pas besoin de redémarrer pour que udev relise les règles (voir unix.stackexchange.com/a/39371/44760 ). J'ai fait mon débogage udev (qui n'est en effet pas la tâche la plus simple!) Avec udevadm testet j'ai validé les règles contre la réalité avec udevadm info.
zagrimsan

Réponses:

11
  • 10-comme mentionné par jasonwryan, utilisez une numérotation élevée (90's good). Donc, votre règle ne sera pas remplacée par une autre.

  • Utilisez les clés minimales comme vous en avez vraiment besoin. Exemple, !=& GOTO/ LABEL, utilisez plutôt directement==

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

  • Votre cible était sdb1avec une commande fixe, minimisez la correspondance aveugle en utilisantKERNEL=="sdb1"

  • Je trouve utile de créer une règle de débogage shadow, j'ai appelé shadow parce que je le laisse toujours là dans le même fichier, donc je l'utilise quand j'en ai besoin.

    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"

    Remarque: udev-env.txt est créé puis la règle est déclenchée de toute façon. Ligne==correspondant à un nœud correspondant. L'ENV enregistré dans ce fichier pourrait être un mélange entre 2 nœuds ou plus, créé presque en même temps, c'est unstdoutproblème de mise en mémoire tampon.

  • L' utilisation udevadm monitor -u, udevadm test ...et udevadm trigger ... de vérifier que les règles traitées les événements.

  • À l'intérieur des scripts, c'est à vous de créer un journal de débogage et d'intercepter les commandes ayant échoué, en enregistrant également leur valeur de retour stdoutet les stderrmessages.

Mise à jour:

  • Référence: 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
la source
1
Très utile. Un couple de commentaires udevadm test...semble ne montrer que les variables d'environnement, que ATTRSvous pouvez utiliser udevadm info $DEVICEpour trouver ces autres paramètres.
Att Righ
1
En udevadm inforetour, une arborescence de périphériques veille à bien distinguer les paramètres entre un périphérique et ses périphériques parents (les propriétés semblent être héritées si elles ne sont pas remplacées). Dans mon cas, le sous-système était incorrect.
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."N'y a-t-il aucun moyen de retracer ce qui se passe réellement ?
MarcH
@MarcH, vous pouvez utiliser udevadm monitor -upour vérifier les événements / conditions et udevadm trigger ...tester leurs actions.
user.dz
@MarcH, mais à l'intérieur des scripts, c'est à vous de créer un journal de débogage et d'intercepter les commandes ayant échoué (en enregistrant leur valeur de retour également les messages stdout et stderr).
user.dz
1

Je pense que la commande que vous recherchez ici est udevadm . Vous utiliserez les paramètres triggeret testpour déclencher une nouvelle analyse des événements udev et pour tester un événement spécifique, respectivement.

J'ai appris cela à la dure lorsque je me suis amusé avec le nouveau nom de périphérique réseau dans EL 7. Bonne chance!

Paul
la source
1

  1. Créer un fichier de règles udev

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

  2. Ajouter une règle qui dit aux udisks de le monter automatiquement

    SUBSYSTEM=="block", SUBSYSTEMS=="mmc", DRIVERS=="mmcblk", ATTRS{type}=="SD", ENV{UDISKS_AUTO}="1", ENV{UDISKS_SYSTEM}="0"

    ATTRS{type}=="SD" peut ne pas être nécessaire si vous utilisez différents types.

  3. Règles de rechargement

    sudo udevadm control -R

  4. Éjectez-le puis remettez-le en place.

Référence: Archlinux Wiki: Certains périphériques, qui doivent être traités comme amovibles, ne sont pas

user.dz
la source
0

J'avais le même problème avec RASPBERRY PI 3 B +, il se pourrait que les commandes ci-dessus puissent vous aider. Mais cela ne m'a pas aidé. J'essayais d'invoquer un script lors de l'insertion d'un périphérique de stockage USB. Les règles ne sont pas enregistrées dans syslog, il devient donc très difficile de comprendre quelle règle a fonctionné ou quelle règle a échoué.

J'ai donc fait ce qui suit:

(1) J'ai créé mon fichier de règles dans /etc/udev/rules.d/100-myrule.rules

(2) puis j'ai exécuté la commande sudo /etc/init.d/udev restart

puis j'ai vérifié que cela fonctionnait. Une information peut vous être utile ou non, mais les systèmes de fichiers sont en lecture seule pour udev jusqu'à ce que la commande at (2) soit exécutée.

MSharq
la source