@Nils На самом деле, вам может понадобиться udevtrigger(или, скорее, udevadm triggerв большинстве дистрибутивов) вместо этого (или подключить устройство и включить его обратно). --reload-rulesпочти всегда бесполезен, поскольку это происходит автоматически.
Жиль
12
udevadm triggerсделал трюк на CentOS 6 для меня.
astrostl
3
udevtriggerили udevadm triggerне работал для меня. Я обнаружил, что некоторые устройства будут работать после выгрузки и загрузки модуля для одного и того же (при условии, что это загружаемый модуль). Я обнаружил, что не обязательно перезагружать систему. Пример для сетевого устройства, я rmmod ixgbe, rmmod tg3, rmmod e1000тогда modprobe ixgbe, modprobe tg3, в modprobe e1000зависимости от типа сетевого драйвера.
энтузиаст
1
Ни одна из вещей, упомянутых среди ответов, не сработала для меня в Debian Jessie (8.0). То, что сработало, ip link set $oldname name $newnameупоминается здесь . В моем случае мне нужно было заменить имя iface lanна мостовое iface (для KVM), и, следовательно, оригинал - теперь лежащий в основе - iface должен был вернуть свое старое имя eth1обратно. Итак, хитрость была в следующем: 1) обрушить ифакс; 2) исправить настройки сети; 3) обновить файл правил именования udev; 4) переименовать iface используя ip link...; 5) поднять мост.
kostix
69
Udev использует механизм inotify для отслеживания изменений в каталоге правил, как в библиотеке, так и в локальных деревьях конфигурации (обычно расположенных в /lib/udev/rules.dи /etc/udev/rules.d). Поэтому в большинстве случаев вам не нужно ничего делать, когда вы меняете файл правил.
Вам нужно только явно уведомить демон udev, если вы делаете что-то необычное, например, если у вас есть правило, включающее файлы в другом каталоге. Затем вы можете использовать обычное соглашение для запроса демонов о перезагрузке их конфигурации: отправьте SIGHUP ( pkill -HUP udevd). Или вы можете использовать udevadmкоманду: udevadm control --reload-rules.
Однако следует помнить, что разные версии udev исторически имели разные триггеры для автоматической перезагрузки правил. Так что если сомневаетесь, звоните udevadm control --reload-rules: это все равно не причинит вреда.
Правила udev применяются только при добавлении устройства. Если вы хотите повторно применить правила к устройству, которое уже подключено, вам нужно сделать это явным образом, вызывая udevadm triggerправильные опции, соответствующие устройству (ам), конфигурация которого была изменена, например udevadm trigger --attr-match=vendor='Yoyodyne' --attr-match=model='Frobnicator 300'.
Использует ли systemd udev команду inotify для отслеживания изменений правил?
Крейг МакКуин
inotifyМеханизм не всегда поймать изменения файла правил Udev. Например, когда я использую cat > 10-name.rulesдля изменения файла правил путем вставки содержимого, я должен перезагрузить правила вручную, используя udevadm. Проверено на растяжке Распбиана.
Даниэль К.
@DanielK. Изменилось ли это недавно? IIRC Я проверил как systemd udev, так и не systemd udev, когда опубликовал этот ответ, и оба использовали inotify, поэтому он --reload-rulesбыл необходим только в редких случаях.
Жиль
@Gilles: возможно, мой пример выше (перезапись существующего файла правил с помощью перенаправления оболочки) можно считать «необычным случаем». Когда я изменил этот файл с помощью редактора, например, vi, inotifyмеханизм сработал.
Даниэль К.
@DanielK. Ах, это приятно знать. Это не редкий случай: некоторые редакторы сохраняют файл, переписывая (с Vim и Emacs, это зависит от того, как они настроены). Странно, что udev обрабатывает только один случай - для меня это похоже на ошибку, потому что я не могу придумать причину относиться к ним по-другому.
Жиль
19
Я добавляю это, потому что однажды мне это понадобится ... снова.
Иногда вы получаете неправильное совпадение номеров устройств Ethernet и MAC-адресов. Иногда это действительно важно, например, при работе на виртуальной машине, и каждому устройству назначается отдельная VLAN.
Отключите сетевые интерфейсы, затем
изменить /etc/udev/rules.d/70-persistent-net.rules(или его эквивалент)
перезагрузить с udevadm control --reload-rules
повторно запустить с udevadm trigger --attr-match=subsystem=net
на Red Hat:service network stop && udevadm control --reload-rules; udevadm trigger --attr-match=subsystem=net; service network start
Александр Торстлинг
1
При тестировании Debian 'udevadm trigger --attr-match = subsystem = net' не работает. Я должен был отключить и подключить USB-карту только тогда, когда udev запустил новое правило.
Трисмегистос
Я хотел бы поспорить, Трисмегистос, что отключение / подключение похоже на удаление и перезагрузку сетевого драйвера, согласно ответу Клейтона Дьюкса.
Майк С
12
Я не уверен, применимо ли это, и это определенно более старая статья, но она поднялась довольно высоко в моем веб-поиске информации udev, поэтому я подумал, что могу поделиться некоторыми знаниями.
Вы можете запускать правила udev вручную для определенных устройств. Это относится только к дистрибутивам, связанным с redhat (centos fedora и т. Д. И т. Д.)
После внесения соответствующих изменений в файл правил ( /etc/udev/rules.d/whateveryoucalledyourrules) вы можете changeперейти к событию устройства.
echo change > /sys/block/devname/partname1/uevent
Это заставит читать правило udev ТОЛЬКО для этого устройства. Гораздо лучше и более целенаправленный, на мой взгляд.
Я добавляю правильный ответ здесь, потому что мне потребовалось некоторое время, чтобы заметить это в комментарии от @enthusiasticgeek. Все, что вам нужно сделать (при условии, что вы находитесь на консоли сервера - ясно, что это плохо, если вы в ssh'd!):
Получите список используемых интерфейсных модулей:
введите sudo rmmod igb(замените igbдрайвером карты, полученным на шаге 1.
затем отредактируйте по /etc/udev/rules.d/70-persistent-net.rulesмере необходимости, затем снова загрузите модуль modprobe igb, снова заменив его своим igb.
Это, в сочетании с ответом Отеуса, было секретным соусом, который позволил мне исправить конфигурацию сетевой карты Mellanox без перезагрузки компьютера. Я полагаю, что загрузка драйвера и чтение udevadm файла persistent-net.rules примерно сродни действиям системы при загрузке.
Майк С
0
в случае нескольких сетей
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
udev
? Это менеджер/dev
?Ответы:
источник
udevtrigger
потом?udevtrigger
(или, скорее,udevadm trigger
в большинстве дистрибутивов) вместо этого (или подключить устройство и включить его обратно).--reload-rules
почти всегда бесполезен, поскольку это происходит автоматически.udevadm trigger
сделал трюк на CentOS 6 для меня.udevtrigger
илиudevadm trigger
не работал для меня. Я обнаружил, что некоторые устройства будут работать после выгрузки и загрузки модуля для одного и того же (при условии, что это загружаемый модуль). Я обнаружил, что не обязательно перезагружать систему. Пример для сетевого устройства, яrmmod ixgbe
,rmmod tg3
,rmmod e1000
тогдаmodprobe ixgbe
,modprobe tg3
, вmodprobe e1000
зависимости от типа сетевого драйвера.ip link set $oldname name $newname
упоминается здесь . В моем случае мне нужно было заменить имя ifacelan
на мостовое iface (для KVM), и, следовательно, оригинал - теперь лежащий в основе - iface должен был вернуть свое старое имяeth1
обратно. Итак, хитрость была в следующем: 1) обрушить ифакс; 2) исправить настройки сети; 3) обновить файл правил именования udev; 4) переименовать iface используяip link...
; 5) поднять мост.Udev использует механизм inotify для отслеживания изменений в каталоге правил, как в библиотеке, так и в локальных деревьях конфигурации (обычно расположенных в
/lib/udev/rules.d
и/etc/udev/rules.d
). Поэтому в большинстве случаев вам не нужно ничего делать, когда вы меняете файл правил.Вам нужно только явно уведомить демон udev, если вы делаете что-то необычное, например, если у вас есть правило, включающее файлы в другом каталоге. Затем вы можете использовать обычное соглашение для запроса демонов о перезагрузке их конфигурации: отправьте SIGHUP (
pkill -HUP udevd
). Или вы можете использоватьudevadm
команду:udevadm control --reload-rules
.Однако следует помнить, что разные версии udev исторически имели разные триггеры для автоматической перезагрузки правил. Так что если сомневаетесь, звоните
udevadm control --reload-rules
: это все равно не причинит вреда.Правила udev применяются только при добавлении устройства. Если вы хотите повторно применить правила к устройству, которое уже подключено, вам нужно сделать это явным образом, вызывая
udevadm trigger
правильные опции, соответствующие устройству (ам), конфигурация которого была изменена, напримерudevadm trigger --attr-match=vendor='Yoyodyne' --attr-match=model='Frobnicator 300'
.источник
inotify
Механизм не всегда поймать изменения файла правил Udev. Например, когда я используюcat > 10-name.rules
для изменения файла правил путем вставки содержимого, я должен перезагрузить правила вручную, используяudevadm
. Проверено на растяжке Распбиана.--reload-rules
был необходим только в редких случаях.inotify
механизм сработал.Я добавляю это, потому что однажды мне это понадобится ... снова.
Иногда вы получаете неправильное совпадение номеров устройств Ethernet и MAC-адресов. Иногда это действительно важно, например, при работе на виртуальной машине, и каждому устройству назначается отдельная VLAN.
/etc/udev/rules.d/70-persistent-net.rules
(или его эквивалент)udevadm control --reload-rules
udevadm trigger --attr-match=subsystem=net
Я был удивлен, насколько хорошо это сработало.
источник
service network stop && udevadm control --reload-rules; udevadm trigger --attr-match=subsystem=net; service network start
Я не уверен, применимо ли это, и это определенно более старая статья, но она поднялась довольно высоко в моем веб-поиске информации udev, поэтому я подумал, что могу поделиться некоторыми знаниями.
Вы можете запускать правила udev вручную для определенных устройств. Это относится только к дистрибутивам, связанным с redhat (centos fedora и т. Д. И т. Д.)
После внесения соответствующих изменений в файл правил (
/etc/udev/rules.d/whateveryoucalledyourrules
) вы можетеchange
перейти к событию устройства.Это заставит читать правило udev ТОЛЬКО для этого устройства. Гораздо лучше и более целенаправленный, на мой взгляд.
источник
Для меня ниже последовательность команд сработала как хотелось.
Я сделал изменения,
/etc/udev/rules.d/70-persistent-net.rules
чтобы изменитьeth
номер и перезагрузить их без перезагрузки.После этого он был успешно загружен во время выполнения без перезагрузки компьютера.
Любые предложения или рекомендации по этому поводу приветствуются, так как я обнаружил это самостоятельно, прочитав страницы руководства.
источник
Я добавляю правильный ответ здесь, потому что мне потребовалось некоторое время, чтобы заметить это в комментарии от @enthusiasticgeek. Все, что вам нужно сделать (при условии, что вы находитесь на консоли сервера - ясно, что это плохо, если вы в ssh'd!):
cat /etc/udev/rules.d/70-persistent-net.rules | grep "PCI device" | perl -pe 's/.*\((\w+)\).*/$1/g'| uniq
В моем случае
igb
так оно и есть.sudo rmmod igb
(заменитеigb
драйвером карты, полученным на шаге 1.затем отредактируйте по
/etc/udev/rules.d/70-persistent-net.rules
мере необходимости, затем снова загрузите модульmodprobe igb
, снова заменив его своимigb
.источник
в случае нескольких сетей
источник