Come ricaricare le regole udev senza riavviare?

210

Come si dovrebbero ricaricare le regole udev, in modo che una nuova creazione possa funzionare?

Sto eseguendo Arch Linux e non ho un udevstartcomando qui.

Anche controllato /etc/rc.d, nessun servizio udev lì.

kernel udev

— margherita
fonte

1

Si noti che le versioni più recenti di udev hanno eliminato il supporto di inotify, pertanto in questi giorni è necessario ricaricare le regole di modifica più spesso.

— Colin Guthrie,

Che cosa è udev? È il manager di /dev?

— Sandburg,

1

@Sandburg sì, gestisce plug-n-play su sistemi Linux.

— Aaron D. Marasco il

231

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

— Ignacio Vazquez-Abrams
fonte

4

Ti serve udevtriggerdopo?

— Nils,

38

@Nils In realtà, potrebbe essere necessario udevtrigger(o meglio udevadm triggernella maggior parte delle distribuzioni) invece (quello, o collegare il dispositivo e ripristinarlo). --reload-rulesè quasi sempre inutile come accade automaticamente.

— Gilles

12

udevadm triggerha fatto il trucco su CentOS 6 per me.

— astrostl

3

udevtriggero udevadm triggernon ha funzionato per me. Ho scoperto che alcuni dispositivi funzioneranno dopo aver scaricato e caricato il modulo per lo stesso (supponendo che sia un modulo caricabile). Quello che ho scoperto è che non è necessario riavviare il sistema. Esempio di un dispositivo di rete, faccio rmmod ixgbe, rmmod tg3, rmmod e1000quindi modprobe ixgbe, modprobe tg3, modprobe e1000a seconda del tipo di driver di rete.

— enthusiasticgeek

1

Nessuna delle cose menzionate tra le risposte ha funzionato per me su Debian Jessie (8.0). La cosa che ha funzionato è ip link set $oldname name $newnamemenzionata qui . Nel mio caso, avevo bisogno di sostituire un iface di nome lancon un iface ponte (per KVM), e, quindi, l'originale - ora sottostante - iface dovuto ottenere il suo vecchio nome, eth1, indietro. Quindi il trucco era: 1) abbattere iface; 2) correggere la configurazione della rete; 3) aggiorna il file delle regole di denominazione udev; 4) rinominare l'iface usando ip link...; 5) solleva il ponte.

— kostix,

69

Udev utilizza il meccanismo inotify per controllare le modifiche nella directory delle regole, sia nella libreria che negli alberi di configurazione locali (generalmente situati in /lib/udev/rules.de /etc/udev/rules.d). Quindi la maggior parte delle volte non è necessario fare nulla quando si modifica un file delle regole.

Devi solo avvisare esplicitamente il demone udev se stai facendo qualcosa di insolito, ad esempio se hai una regola che include file in un'altra directory. Quindi puoi usare la solita convenzione per chiedere ai demoni di ricaricare la loro configurazione: invia un SIGHUP ( pkill -HUP udevd). Oppure si può utilizzare il udevadmcomando: udevadm control --reload-rules.

Tuttavia, attenzione che diverse versioni di udev hanno storicamente avuto diversi trigger per ricaricare automaticamente le regole. Quindi, in caso di dubbio, chiama udevadm control --reload-rules: non farà comunque alcun danno.

Le regole udev vengono applicate solo quando viene aggiunto un dispositivo. Se si desidera applicare nuovamente le regole a un dispositivo già connesso, è necessario farlo esplicitamente, chiamando udevadm triggerle opzioni giuste per abbinare i dispositivi la cui configurazione è cambiata, ad es udevadm trigger --attr-match=vendor='Yoyodyne' --attr-match=model='Frobnicator 300'.

— Gilles
fonte

1

Systemd udev utilizza inotify per controllare le modifiche alle regole?

— Craig McQueen,

Il inotifymeccanismo non rileva sempre una modifica di un file di regole udev. Ad esempio, quando uso cat > 10-name.rulesper modificare il file delle regole incollando il contenuto, devo ricaricare le regole manualmente usando udevadm. Testato su Raspbian Stretch.

— Daniel K.

@DanielK. È cambiato di recente? IIRC Ho controllato sia un udev di sistema sia un udev non di sistema quando ho pubblicato questa risposta, ed entrambi hanno usato inotify, quindi --reload-rulesera necessario solo in casi non comuni.

— Gilles,

@Gilles: forse il mio esempio sopra (sovrascrivere un file di regole esistente usando il reindirizzamento della shell) può essere considerato un "caso non comune". Quando ho modificato questo file tramite un editor, ad esempio vi, il inotifymeccanismo ha funzionato.

— Daniel K.

@DanielK. Ah, è buono a sapersi. Non è un caso insolito: alcuni editor salverebbero il file riscrivendolo (con Vim ed Emacs, dipende da come sono configurati). Strano che udev gestisca solo uno dei casi - mi sembra un bug, perché non riesco a pensare a un motivo per trattarli in modo diverso.

— Gilles,

19

Sto aggiungendo questo perché un giorno ne avrò bisogno ... di nuovo.

A volte si ottiene una corrispondenza errata dei numeri di dispositivo Ethernet e degli indirizzi MAC. A volte questo è davvero importante, come quando si esegue in una macchina virtuale e ogni dispositivo è assegnato a una VLAN diversa.

Abbassa quindi le interfacce di rete
modifica /etc/udev/rules.d/70-persistent-net.rules(o suo equivalente)
ricaricare con udevadm control --reload-rules
riattivare con udevadm trigger --attr-match=subsystem=net
porta su le interfacce di rete.

Sono rimasto sorpreso da quanto funzionasse.

— Otheus
fonte

6

su Red Hat:

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

— Alexander Torstling,

1

Nel test Debian 'udevadm trigger --attr-match = sottosistema = net' non funziona. Ho dovuto scollegare e collegare la scheda Ethernet USB solo allora udev ha innescato una nuova regola.

— Trismegistos,

Sarei disposto a scommettere, Trismegistos, che la disconnessione / spina è simile alla rimozione e al ricaricamento del driver di rete, secondo la risposta di Clayton Dukes.

— Mike S,

12

Non sono sicuro se questo si applica, e questo è sicuramente un post più vecchio, ma è arrivato piuttosto in alto la mia ricerca web per informazioni su udev, quindi ho pensato di condividere alcune conoscenze.

È possibile attivare manualmente le regole udev per dispositivi specifici. Questo vale solo per le distribuzioni relative a redhat (centos fedora ecc ecc ecc)

Dopo aver apportato le modifiche pertinenti nel file delle regole ( /etc/udev/rules.d/whateveryoucalledyourrules), è possibile echeggiare changenell'event del dispositivo.

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

Questo forzerà la lettura di una regola udev SOLO per questo dispositivo. Molto meglio e più mirato secondo me.

— mbadmin
fonte

4

Per me, la sequenza di comandi di seguito ha funzionato come desiderato.

Ho apportato modifiche /etc/udev/rules.d/70-persistent-net.rulesper modificare il ethnumero e ricaricarli senza riavviare.

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

In seguito, è stato caricato correttamente in fase di esecuzione senza riavviare la macchina.

Qualsiasi suggerimento o consiglio su questo è il benvenuto, come ho scoperto da solo leggendo le pagine man.

— Aditya Malviya
fonte

2

Sto aggiungendo la risposta corretta qui perché mi ci è voluto un po 'di tempo per notarla nel commento di @enthusiasticgeek. Tutto quello che devi fare (supponendo che tu sia sulla console del server - chiaramente questo è male da fare se sei entrato!):

Ottieni un elenco dei moduli di interfaccia utilizzati:

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

Nel mio caso, lo è igb, quindi stampa proprio quello.

digitare sudo rmmod igb(sostituire igbcon il driver della scheda ottenuto dal passaggio 1.

quindi, modifica /etc/udev/rules.d/70-persistent-net.rulessecondo necessità, quindi carica nuovamente il modulo utilizzando modprobe igb, nuovamente sostituendolo igbcon il tuo.

— Clayton Dukes
fonte

Questo, combinato con la risposta di Otheus, è stata la salsa segreta che mi ha permesso di correggere la configurazione della mia scheda di rete Mellanox senza riavviare la macchina. Credo che il caricamento del driver e la lettura udevadm del file persistent-net.rules siano approssimativamente simili a quello che fa il sistema all'avvio.

— Mike S,

0

in caso di più reti

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
fonte