Як перезавантажити правила udev без перезавантаження?


209

Як слід перезавантажувати правила udev, щоб новостворене могло функціонувати?

Я запускаю Arch Linux, і тут я не маю udevstartкоманди.

Також перевірено /etc/rc.d, немає жодної послуги udev.


1
Зауважте, що новіші версії udev відмовилися від підтримки inotify, тому перезавантаження правил про зміни потрібно частіше в ці дні.
Колін Гатрі

Що таке udev? Це менеджер /dev?
Сандбург

1
@Sandburg так, він обробляє plug-n-play в системах Linux.
Аарон Д. Мараско

Відповіді:


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

4
Вам потрібно udevtriggerпісля цього?
Нілс

38
@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залежності від типу мережевого драйвера.
enthusiasticgeek

1
Жодна з речей, згаданих серед відповідей, не працювала для мене над Debian Jessie (8.0). Те, що працювало, ip link set $oldname name $newnameзгадується тут . У моєму випадку мені потрібно було замінити іфаце, названий lanмостовим іфацею (для KVM), а отже, оригінал - тепер лежить в основі - iface повинен був отримати свою стару назву eth1,,. Отже, хитрість полягала в тому, щоб: 1) збити iface вниз; 2) виправити налаштування мережі; 3) оновити файл правил іменування udev; 4) перейменуйте iface за допомогою ip link...; 5) піднести міст вгору.
kostix

69

Udev використовує механізм inotify для спостереження за змінами в каталозі правил, як у бібліотеці, так і в локальних деревах конфігурації (як правило, розташовані в /lib/udev/rules.dі /etc/udev/rules.d). Тому більшу частину часу вам нічого не потрібно робити, змінюючи файл правил.

Потрібно сповістити про це демон демон тільки, якщо ви робите щось незвичне, наприклад, якщо у вас є правило, яке включає файли в іншому каталозі. Тоді ви можете скористатися звичайною умовою для запиту демонів перезавантажити їх конфігурацію: надішліть 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'.


1
Чи використовує systemd udev inotify для спостереження за зміною правила?
Крейг МакКуін

inotifyМеханізм не завжди зловити зміни файлу правил Udev. Наприклад, коли я використовую cat > 10-name.rulesдля зміни файла правил, вставляючи вміст, я повинен перезавантажувати правила вручну, використовуючи udevadm. Випробуваний на Raspbian Stretch.
Даніель К.

@DanielK. Чи змінилося це нещодавно? IIRC Я перевіряв як системний удев, так і несистемний удев, коли я публікував цю відповідь, і обидва використовували inotify, тому це --reload-rulesбуло потрібно лише у рідкісних випадках.
Жиль

@Gilles: можливо мій приклад, наведений вище (перезапис існуючого файлу правил за допомогою перенаправлення оболонки), може вважатися "непоодиноким випадком". Коли я змінив цей файл за допомогою редактора, наприклад, vi, inotifyмеханізм спрацював.
Даніель К.

@DanielK. Ах, це добре знати. Це не рідкісний випадок: деякі редактори зберігають файл шляхом перезапису (для Vim та Emacs, це залежить від їх налаштування). Дивно, що удев займається лише одним із випадків - мені це здається помилкою, тому що я не можу придумати причину, щоб по-іншому ставитися до них.
Жиль

19

Я додаю це, тому що якихось день мені знадобиться ... знову.

Іноді ви отримуєте неправильну відповідність номерів пристроїв Ethernet та MAC-адрес. Іноді це дійсно важливо, як, наприклад, під час роботи у ВМ, і кожен пристрій призначений для іншої VLAN.

  1. Потім знижте мережеві інтерфейси
  2. змінити /etc/udev/rules.d/70-persistent-net.rules(або його еквівалент)
  3. перезавантажити с udevadm control --reload-rules
  4. повторний запуск с udevadm trigger --attr-match=subsystem=net
  5. піднести мережеві інтерфейси.

Я був здивований, як добре це спрацювало.


6
on Red Hat:service network stop && udevadm control --reload-rules; udevadm trigger --attr-match=subsystem=net; service network start
Олександр Торстлінг

1
На тестуванні Debian 'udevadm тригер --attr-match = підсистема = net' не працює. Мені довелося вимкнути підключення та підключити USB-ефірну карту лише тоді, коли udev запустило нове правило.
Trismegistos

Я б хотів зробити ставку, Трисмегісто, що відключення штекера / штекера схоже на вилучення та перезавантаження мережевого драйвера, відповідно до відповіді Клейтона Дюкеса.
Майк S

12

Я не впевнений, чи це стосується, і це, безумовно, старіший пост, але це було дуже великим моїм веб-пошуком інформації про udev, тому я подумав, що можу поділитися деякими знаннями.

Ви можете запустити правила udev вручну для конкретних пристроїв. Це стосується лише дистрибутивів, пов'язаних з Redhat (centos fedora тощо, тощо, тощо)

Після того як ви внесете відповідні зміни у файл своїх правил ( /etc/udev/rules.d/whateveryoucalledyourrules), ви зможете повторитись changeдо події пристрою.

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

Це змусить зчитувати правило udev для ТІЛЬКИ цього пристрою. Набагато краще і більш цілеспрямовано, на мою думку.


4

Для мене нижче командна послідовність спрацювала так, як хочеться.

Я вніс зміни, /etc/udev/rules.d/70-persistent-net.rulesщоб змінити ethномер та перезавантажити їх без перезавантаження.

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

Слідом за цим, він був успішно завантажений під час роботи без перезавантаження машини.

Будь-яка пропозиція чи рекомендації щодо цього вітаються, оскільки я виявив це самостійно, читаючи чоловічі сторінки.


2

Я додаю тут правильну відповідь, тому що мені знадобилося певний час, щоб помітити це у коментарі від @enthusiasticgeek. Все, що вам потрібно зробити (якщо припустити, що ви знаходитесь на консолі сервера - очевидно, що це погано робити, якщо ви входите!):

  1. Отримайте список використовуваних модулів інтерфейсу:

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

У моєму випадку це igbтак, тож воно друкує саме так.

  1. введіть sudo rmmod igb(замініть igbдрайвером картки, отриманим з кроку 1.

далі, відредагуйте /etc/udev/rules.d/70-persistent-net.rulesза потребою, потім знову завантажте модуль за допомогою modprobe igb, знову замінивши свій igb.


Це в поєднанні з відповіддю Отея було таємним соусом, який дозволив мені виправити конфігурацію мережевої картки Mellanox без машинного перезавантаження. Я вважаю, що завантаження драйвера та прочитаний udevadm файлу persistent-net.rules приблизно схоже на те, що робить система під час завантаження.
Майк S

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
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.