Jak przeładować reguły udev bez restartu?

209

Jak należy przeładować reguły udev, aby nowo utworzony mógł funkcjonować?

Korzystam z Arch Linux i nie mam tu udevstartpolecenia.

Sprawdzono również /etc/rc.d, nie ma tam usługi udev.

kernel udev

— stokrotka
źródło

1

Należy pamiętać, że nowsze wersje udev porzuciły obsługę inotify, więc przeładowanie reguł dotyczących zmian jest obecnie potrzebne częściej.

— Colin Guthrie,

Co to jest udev? Czy to kierownik /dev?

— Sandburg,

1

@ Sandburg tak, obsługuje plug-n-play w systemach Linux.

— Aaron D. Marasco

229

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

— Ignacio Vazquez-Abrams
źródło

4

Czy potrzebujesz udevtriggerpóźniej?

— Nils

38

@Nils Właściwie zamiast tego możesz potrzebować udevtrigger(a raczej udevadm triggerw większości dystrybucji) (to, lub podłączyć urządzenie i włożyć z powrotem). --reload-rulesjest prawie zawsze bezużyteczne, ponieważ dzieje się to automatycznie.

— Gilles

12

udevadm triggerwykonał dla mnie lewę na CentOS 6.

— astrostl

3

udevtriggerlub udevadm triggernie działało dla mnie. Odkryłem, że niektóre urządzenia będą działać po rozładowaniu i załadowaniu modułu dla tego samego (zakładając, że jest to moduł do załadowania). Dowiedziałem się, że niekoniecznie trzeba ponownie uruchomić system. Przykład dla urządzenia sieciowego, robię rmmod ixgbe, rmmod tg3, rmmod e1000następnie modprobe ixgbe, modprobe tg3, modprobe e1000w zależności od rodzaju sterownika sieciowego.

— entuzjastyczny

1

Żadna z rzeczy wymienionych w odpowiedziach nie działała dla mnie w Debian Jessie (8.0). O rzeczy, która działała, ip link set $oldname name $newnamewspomniano tutaj . W moim przypadku musiałem zastąpić iface o nazwie lanzmostkowany iface (dla KVM), a zatem pierwotny - teraz leżący u podstaw - iface musiał odzyskać swoją starą nazwę eth1. Zatem sztuczka polegała na: 1) sprowadzeniu iface; 2) napraw konfigurację sieci; 3) zaktualizuj plik reguł nazewnictwa udev; 4) zmienić nazwę iface za pomocą ip link...; 5) podnieś most.

— kostix

69

Udev używa mechanizmu inotify do obserwowania zmian w katalogu reguł, zarówno w bibliotece, jak i w lokalnych drzewach konfiguracji (zwykle zlokalizowanych w /lib/udev/rules.di /etc/udev/rules.d). Dlatego przez większość czasu nie musisz nic robić, gdy zmieniasz plik reguł.

Musisz tylko wyraźnie powiadomić demona udev, jeśli robisz coś niezwykłego, na przykład jeśli masz regułę obejmującą pliki z innego katalogu. Następnie możesz użyć zwykłej konwencji, aby poprosić demony o ponowne załadowanie ich konfiguracji: wyślij SIGHUP ( pkill -HUP udevd). Albo można użyć udevadmpolecenia: udevadm control --reload-rules.

Należy jednak pamiętać, że różne wersje udev w przeszłości miały różne wyzwalacze do automatycznego ponownego ładowania reguł. W razie wątpliwości zadzwoń udevadm control --reload-rules: i tak nie zaszkodzi.

Reguły udev są stosowane tylko po dodaniu urządzenia. Jeśli chcesz ponownie zastosować reguły do urządzenia, które jest już podłączone, musisz to zrobić jawnie, dzwoniąc udevadm triggerz odpowiednimi opcjami, aby dopasować urządzenie (urządzenia), których konfiguracja uległa zmianie, np udevadm trigger --attr-match=vendor='Yoyodyne' --attr-match=model='Frobnicator 300'.

— Gilles
źródło

1

Czy systemd udev używa inotify do obserwowania zmian reguł?

— Craig McQueen

inotifyMechanizm nie zawsze złapać zmianę pliku reguł udev. Na przykład, kiedy używam cat > 10-name.rulesdo zmiany pliku reguł przez wklejenie zawartości, muszę ponownie załadować reguły ręcznie, używając udevadm. Testowany na Raspbian Stretch.

— Daniel K.

@DanielK. Czy to się ostatnio zmieniło? IIRC Sprawdziłem zarówno udev systemd, jak i udev niesystemd, kiedy opublikowałem tę odpowiedź, i oba użyły inotify, więc --reload-rulesbyło to potrzebne tylko w rzadkich przypadkach.

— Gilles

@Gilles: może mój powyższy przykład (zastąpienie istniejącego pliku reguł za pomocą przekierowania powłoki) można uznać za „rzadki przypadek”. Gdy zmodyfikowałem ten plik za pomocą edytora, np. Vi, inotifymechanizm działał.

— Daniel K.

@DanielK. Ach, dobrze wiedzieć. Nie jest to rzadki przypadek: niektórzy redaktorzy zapisują plik, przepisując go ponownie (w Vimie i Emacsie zależy to od ich konfiguracji). Dziwne, że udev obsługuje tylko jeden przypadek - wygląda mi to na błąd, ponieważ nie mogę wymyślić powodu, by traktować je inaczej.

— Gilles

19

Dodam to, bo kiedyś będę tego potrzebować ... znowu.

Czasami pojawia się nieprawidłowe dopasowanie numerów urządzeń Ethernet i adresów MAC. Czasami jest to naprawdę ważne, na przykład podczas pracy na maszynie wirtualnej, a każde urządzenie jest przypisane do innej sieci VLAN.

Opuść interfejsy sieciowe
modyfikować /etc/udev/rules.d/70-persistent-net.rules(lub jego odpowiednik)
załaduj ponownie za pomocą udevadm control --reload-rules
ponownie uruchomić za pomocą udevadm trigger --attr-match=subsystem=net
uruchom interfejsy sieciowe.

Byłem zaskoczony, jak dobrze to działało.

— Otheus
źródło

6

w Red Hat:

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

— Alexander Torstling

1

W testach Debiana „wyzwalacz udevadm --attr-match = podsystem = net” nie działa. Musiałem odłączyć i podłączyć kartę Ethernet USB dopiero wtedy udev uruchomił nową regułę.

— Trismegistos

Byłbym skłonny założyć się, Trismegistos, że odłączenie / wtyczka przypomina usuwanie i ponowne ładowanie sterownika sieciowego, zgodnie z odpowiedzią Claytona Dukesa.

— Mike S

12

Nie jestem pewien, czy to dotyczy, i jest to zdecydowanie starszy post, ale pojawił się dość wysoko w moich wyszukiwaniach informacji udev, więc pomyślałem, że mogę podzielić się wiedzą.

Możesz uruchomić reguły udev ręcznie dla określonych urządzeń. Dotyczy to tylko dystrybucji związanych z redhat (centos fedora itp. Itp.)

Po wprowadzeniu odpowiednich zmian w pliku reguł ( /etc/udev/rules.d/whateveryoucalledyourrules) możesz powtórzyć echo changeurządzenia.

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

Wymusi to odczyt reguły udev TYLKO dla tego urządzenia. Moim zdaniem znacznie lepiej i bardziej ukierunkowany.

— mbadmin
źródło

4

Dla mnie poniższa sekwencja poleceń działała zgodnie z oczekiwaniami.

Wprowadziłem modyfikacje, /etc/udev/rules.d/70-persistent-net.rulesaby zmienić ethnumer i załadować je ponownie bez ponownego uruchamiania.

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

Dzięki temu pomyślnie załadowano go w czasie wykonywania bez ponownego uruchamiania komputera.

Wszelkie sugestie lub zalecenia na ten temat są mile widziane, ponieważ odkryłem to sam, czytając strony podręcznika użytkownika.

— Aditya Malviya
źródło

2

Dodaję do poprawnej odpowiedzi tutaj bo zajęło mi trochę czasu, aby zauważyć w komentarzu z @enthusiasticgeek. Wszystko, co musisz zrobić (zakładając, że jesteś na konsoli serwera - najwyraźniej jest to złe, jeśli jesteś zalogowany!):

Uzyskaj listę używanych modułów interfejsu:

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

W moim przypadku tak jest igb, więc drukuje właśnie to.

wpisz sudo rmmod igb(zamień igbna sterownik karty uzyskany w kroku 1.

następnie edytuj /etc/udev/rules.d/70-persistent-net.rulesw razie potrzeby, a następnie ponownie załaduj moduł za pomocą modprobe igb, ponownie zastępując igbgo swoim.

— Clayton Dukes
źródło

To, w połączeniu z odpowiedzią Otheusa, było tajnym sosem, który pozwolił mi naprawić konfigurację mojej karty sieciowej Mellanox bez ponownego uruchamiania komputera. Uważam, że ładowanie sterownika i odczyt udevadm pliku persistent-net.rules jest mniej więcej podobny do tego, co robi system podczas uruchamiania.

— Mike S

0

w przypadku wielu sieci

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
źródło