Comment recharger les règles udev sans redémarrer?

210

Comment doit-on recharger les règles udev pour que la nouvelle créée puisse fonctionner?

Je suis sous Arch Linux, et je n'ai pas de udevstartcommande ici.

Également vérifié /etc/rc.d, pas de service d'udev là

kernel udev

— Marguerite
source

1

Veuillez noter que les versions les plus récentes d'udev ont abandonné la prise en charge d'inotify, de sorte que le rechargement des règles de changement est nécessaire plus souvent ces jours-ci.

— Colin Guthrie

C'est quoi udev? Est-ce le gestionnaire de /dev?

— Sandburg

1

@ Sandburg oui, il gère le plug-and-play sur les systèmes Linux.

— Aaron D. Marasco

231

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

— Ignacio Vazquez-Abrams
source

4

Avez-vous besoin udevtriggeraprès?

— Nils

38

@ Nils En fait, vous pouvez avoir besoin udevtrigger(ou plutôt udevadm triggersur la plupart des distributions) (ou bien, ou brancher le périphérique et le sauvegarder). --reload-rulesest presque toujours inutile car cela se produit automatiquement.

— Gilles

12

udevadm triggerfait le tour sur CentOS 6 pour moi.

— astrostl

3

udevtriggerou udevadm triggern'a pas fonctionné pour moi. J'ai trouvé que certains périphériques fonctionneraient après le déchargement et le chargement du module (en supposant qu'il s'agisse d'un module chargeable). Ce que j’ai découvert, c’est qu’il n’est pas nécessaire de redémarrer le système. Exemple pour un dispositif de réseau, je fais rmmod ixgbe, rmmod tg3, rmmod e1000puis modprobe ixgbe, modprobe tg3, modprobe e1000selon le type de pilote réseau.

— enthousiastegeek

1

Aucune des choses mentionnées parmi les réponses n'a fonctionné pour moi sur Debian Jessie (8.0). La chose qui a fonctionné est ip link set $oldname name $newnamementionnée ici . Dans mon cas, je devais remplacer un iface nommé lanpar un pont iface (pour KVM), et par conséquent l'original - maintenant sous - jacente - iface a dû obtenir son ancien nom, eth1, le dos. Le truc était donc le suivant: 1) faire tomber iface; 2) réparer la configuration du réseau; 3) mettre à jour le fichier de règles de nommage udev; 4) renommer le iface using ip link...; 5) faire monter le pont.

— Kostix

69

Udev utilise le mécanisme inotify pour surveiller les modifications dans le répertoire rules, à la fois dans la bibliothèque et dans les arborescences de configuration locales (généralement situées à /lib/udev/rules.det /etc/udev/rules.d). Donc, la plupart du temps, vous n'avez rien à faire lorsque vous modifiez un fichier de règles.

Vous devez uniquement informer explicitement le démon udev si vous faites quelque chose d'inhabituel, par exemple si vous avez une règle qui inclut les fichiers dans un autre répertoire. Ensuite, vous pouvez utiliser la convention habituelle pour demander aux démons de recharger leur configuration: envoyez un SIGHUP ( pkill -HUP udevd). Ou vous pouvez utiliser la udevadmcommande: udevadm control --reload-rules.

Cependant, sachez que différentes versions d'udev ont toujours eu différents déclencheurs pour recharger les règles automatiquement. Donc, en cas de doute, appelez udevadm control --reload-rules: cela ne fera aucun mal de toute façon.

Les règles udev ne sont appliquées que lorsqu'un périphérique est ajouté. Si vous souhaitez réappliquer les règles à un périphérique déjà connecté, vous devez le faire de manière explicite, en appelant udevadm triggeravec les options appropriées pour faire correspondre le ou les périphériques dont la configuration a été modifiée, par exemple udevadm trigger --attr-match=vendor='Yoyodyne' --attr-match=model='Frobnicator 300'.

— Gilles
source

1

Systemd udev utilise-t-il inotify pour surveiller les modifications de règles?

— Craig McQueen

Le inotifymécanisme n'intercepte pas toujours le changement d'un fichier de règles udev. Par exemple, lorsque je cat > 10-name.rulesmodifie le fichier de règles en collant le contenu, je dois recharger les règles manuellement à l'aide de udevadm. Testé sur Raspbian Stretch.

— Daniel K.

@DanielK. Cela a-t-il changé récemment? Le IIRC, j’ai vérifié cette information lorsque j’ai posté cette réponse. Les deux ont utilisé inotify et n’ont donc --reload-rulesété nécessaires que dans des cas peu communs.

— Gilles

@Gilles: peut-être que mon exemple ci-dessus (écrasement d'un fichier de règles existant à l'aide de la redirection de shell) peut être considéré comme un "cas inhabituel". Lorsque j'ai modifié ce fichier à l'aide d'un éditeur, par exemple vi, le inotifymécanisme a fonctionné.

— Daniel K.

@DanielK. Ah, c'est bon à savoir. Ce n'est pas un cas rare: certains éditeurs sauvegardent le fichier en le réécrivant (avec Vim et Emacs, cela dépend de leur configuration). Bizarre que udev ne traite qu'un cas - cela me semble être un bug, car je ne vois pas de raison de les traiter différemment.

— Gilles

19

J'ajoute ceci parce qu'un jour j'en aurai besoin ... encore.

Parfois, vous obtenez une correspondance incorrecte des numéros de périphériques Ethernet et des adresses MAC. Parfois, cela est vraiment important, comme lors de l’exécution sur une machine virtuelle et que chaque périphérique est affecté à un VLAN différent.

Abaissez les interfaces réseau, puis
modifier /etc/udev/rules.d/70-persistent-net.rules(ou son équivalent)
recharger avec udevadm control --reload-rules
re-déclencher avec udevadm trigger --attr-match=subsystem=net
mettre les interfaces réseau en place.

J'ai été surpris de voir comment cela fonctionnait bien.

— Otheus
source

6

sur Red Hat:

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

— Alexander Torstling

1

Sur Debian, tester 'udevadm trigger --attr-match = sous-système = net' ne fonctionne pas. Je devais débrancher et brancher la carte Ethernet USB seulement à ce moment-là, udev a déclenché une nouvelle règle.

— Trismegistos

Je serais prêt à parier, Trismegistos, que le débranchement / la prise est assimilable à la suppression et au rechargement du pilote de réseau, comme indiqué dans la réponse de Clayton Dukes.

— Mike S

12

Je ne sais pas si cela s'applique, et ceci est certainement un article ancien, mais ma recherche sur le Web pour udev info a été assez élevée et j'ai donc pensé pouvoir partager certaines connaissances.

Vous pouvez déclencher manuellement les règles udev pour des périphériques spécifiques. Ceci s’applique uniquement aux distributions liées à RedHat (centos fedora, etc., etc.).

Une fois que vous avez apporté les modifications appropriées dans votre fichier de règles ( /etc/udev/rules.d/whateveryoucalledyourrules), vous pouvez changeafficher un écho dans le message de l'appareil.

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

Cela forcera une lecture de règle udev pour SEULEMENT ce périphérique. Bien mieux, et plus ciblé à mon avis.

— mbadmin
source

4

Pour moi, la séquence de commande ci-dessous a fonctionné comme souhaité.

J'ai apporté des modifications /etc/udev/rules.d/70-persistent-net.rulespour changer le ethnuméro et les recharger sans redémarrer.

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

En suivant ceci, il a été chargé avec succès au moment de l’exécution sans redémarrer la machine.

Toute suggestion ou recommandation à ce sujet est la bienvenue, car je l’ai découvert par moi-même en lisant les pages de manuel.

— Aditya Malviya
source

2

J'ajoute la bonne réponse ici car il m'a fallu un certain temps pour le remarquer dans le commentaire de @enthusiasticgeek. Tout ce que vous devez faire (en supposant que vous êtes sur la console du serveur - clairement, c'est mauvais à faire si vous êtes ssh'd!):

Obtenez une liste des modules d'interface utilisés:

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

En ce qui me concerne, c’est igbce qui est imprimé.

type sudo rmmod igb(remplacez igbpar le pilote de votre carte obtenu à l’étape 1.

Ensuite, éditez /etc/udev/rules.d/70-persistent-net.rulesau besoin, puis chargez le module à modprobe igbnouveau en le remplaçant igbpar le vôtre.

— Clayton Dukes
source

Ceci, associé à la réponse d'Otheus, était la sauce secrète qui m'a permis de corriger la configuration de ma carte réseau Mellanox sans redémarrage de la machine. Je crois que le chargement du pilote et la lecture par udevadm du fichier persistent-net.rules ressemblent à peu près à ce que le système fait lors du démarrage.

— Mike S

0

en cas de réseaux multiples

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
source