web-dev-qa-db-ja.com

再起動せずにudevルールをリロードする方法は？

新しく作成されたルールが機能できるようにするには、どのようにudevルールをリロードする必要がありますか？

Arch Linuxを実行していますが、ここにudevstartコマンドがありません。

こちらもチェック/etc/rc.d、udevサービスはありません。

kerneludev
226
daisy
# udevadm control --reload-rules && udevadm trigger
258
Ignacio Vazquez-Abrams

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'。

70
Gilles 'SO- stop being evil'

いつか必要になるので、これを追加します...もう一度。

イーサネットデバイス番号とMACアドレスが正しく一致しない場合があります。 VMで実行していて、各デバイスが異なるVLANに割り当てられている場合など、これは非常に重要です。

  1. ネットワークインターフェイスを停止してから、
  2. /etc/udev/rules.d/70-persistent-net.rules（またはそれに相当するもの）を変更します。
  3. udevadm control --reload-rulesで再読み込み
  4. udevadm trigger --attr-match=subsystem=netで再トリガー
  5. ネットワークインターフェイスを起動します。

これがうまく機能することに驚きました。

19
Otheus

これが当てはまるかどうかは分かりませんが、これは間違いなく古い投稿ですが、udev情報のWeb検索がかなり高くなったので、知識を共有したいと思いました。

特定のデバイスに対してudevルールを手動でトリガーできます。これはredhat関連のディストリビューション（centos Fedoraなどなど）にのみ適用されます

ルールファイル（/etc/udev/rules.d/whateveryoucalledyourrules）、デバイスのueventにchangeをエコーできます。

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

これにより、このデバイスのみのudevルール読み取りが強制されます。私の意見では、はるかに優れており、より的を絞っています。

13
mbadmin

私にとって、以下のコマンドシーケンスは期待どおりに機能しています。

/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

これにより、マシンを再起動せずに実行時に正常にロードされました。

マニュアルページを読んで自分で見つけたので、これに関する提案や提案は大歓迎です。

4
Aditya Malviya

@enthusiasticgeekからのコメントで気づくまでに少し時間がかかったので、ここに正解の回答を追加します。あなたがする必要があるすべて（あなたがサーバーのコンソールにいると仮定します-sshされているなら明らかにこれは悪いことです！）：

  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を自分のものに置き換えます。

2
Clayton Dukes

これは 主な答え からのわずかな変更です：両方のコマンドでSudoが必要であるように思われました。

事例証拠：Sudo udevadm triggerは2秒ほどかかりましたが、Sudoを使用してそれを行うと、0.2秒しかかかりませんでした。ですから、彼らは私のために同じことをしていません。代わりにこれを行ってください：

Sudo udevadm control --reload-rules
Sudo udevadm trigger

そして最後に（以下の2番目のリンクに従って）、デバイスを取り外し、再び差し込みます。

参照：

  1. 再起動せずにudevルールをリロードするには？
  2. https://askubuntu.com/questions/1048870/permission-denied-to-non-root-user-for-usb-device/1187646#1187646

上記の両方の回答の下のコメントも参照してください。

1
Gabriel Staples

複数のネットワークの場合

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
0
alex tmp