リブートせずにudevルールをリロードする方法は？

210

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

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

また/etc/rc.d、そこにudevサービスはありません。

kernel udev

— デイジー
ソース

1

udevの最新バージョンではinotifyサポートが廃止されているため、最近では変更に関するルールの再読み込みがより頻繁に必要になることに注意してください。

— コリンガスリー

なにudev？それはマネージャー/devですか？

— サンドバーグ

1

@Sandburgはい、Linuxシステムでプラグアンドプレイを処理します。

— アーロンD.マラスコ

231

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

— イグナシオ・バスケス・アブラムス
ソース

4

udevtrigger後で必要ですか？

— ニルス

38

@Nils実際には、代わりにudevtrigger（またはudevadm trigger、ほとんどのディストリビューションで）必要になる場合があります（つまり、デバイスを接続して、それを元に戻します）。--reload-rules自動的に行われるため、ほとんどの場合は役に立ちません。

— ジル

12

udevadm triggerCentOS 6で私のためにトリックをしました。

— 宇宙飛行士

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記載されています。私の場合、私は名前lan付きのifaceを（KVM用の）ブリッジされたifaceに置き換える必要がありました。そのため、元の（現在は基礎となっている）ifaceは古い名前eth1を取り戻す必要がありました。トリックは次のとおりです。1）ifaceをダウンさせます。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'。

— ジル
ソース

1

systemd udevはinotifyを使用してルールの変更を監視しますか？

— クレイグマックイーン

このinotifyメカニズムは、常にudevルールファイルの変更をキャッチするとは限りません。たとえばcat > 10-name.rules、コンテンツを貼り付けてルールファイルを変更する場合、を使用してルールを手動でリロードする必要がありudevadmます。Raspbian Stretchでテスト済み。

— ダニエルK.

@DanielK。これは最近変更されましたか？IIRCこの回答を投稿したときにsystemd udevとnon-systemd udevの両方をチェックしました。どちらもinotifyを使用した--reload-rulesため、まれにしか必要ありませんでした。

— ジル

@Gilles：上記の私の例（シェルリダイレクトを使用して既存のルールファイルを上書きする）は、「珍しいケース」であると考えることができます。viなどのエディターを使用してこのファイルを変更すると、inotifyメカニズムが機能しました。

— ダニエルK.

@DanielK。ああ、それは知っておくべきことです。珍しいケースではありません。一部のエディターは、書き換えによってファイルを保存します（VimとEmacsでは、設定方法によって異なります）。奇妙なことに、udevはケースの1つだけを処理します。これはバグのように見えます。これを別の方法で扱う理由を考えることができないからです。

— ジル

19

いつか必要になるので、これを追加します...再び。

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

ネットワークインターフェイスを停止してから、
変更/etc/udev/rules.d/70-persistent-net.rules（またはその同等）
でリロード udevadm control --reload-rules
で再トリガー udevadm trigger --attr-match=subsystem=net
ネットワークインターフェイスを起動します。

私はこれがどれほどうまく機能したかに驚いた。

— オテウス
ソース

6

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が新しいルールをトリガーしました。

— トリメジストス

クレイトン・デュークスの答えによると、プラグ/プラグはネットワークドライバーの削除と再ロードに似ていると、Trismegistosに喜んで賭けたいと思います。

— マイクS

12

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

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

ルールファイル（/etc/udev/rules.d/whateveryoucalledyourrules）で関連する変更を行ったらchange、デバイスのueventにエコーインできます。

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

これにより、このデバイスのみに対してudevルールの読み取りが強制されます。私の意見でははるかに良く、よりターゲットを絞っています。

— mbadmin
ソース

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のコメントで気づくまでに時間がかかったため、ここに正しい答えを追加します。あなたがする必要があるのは、あなたがサーバーのコンソール上にいると仮定します-明らかに、あなたが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ます。

— クレイトン・デュークス
ソース

これは、オテウスの答えと相まって、マシンを再起動せずにMellanoxネットワークカードの設定を修正できる秘密のソースでした。ドライバーのロードと、persistent-net.rulesファイルのudevadmの読み取りは、ブート時にシステムが行う動作とほぼ同じであると思います。

— マイク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

— アレックスtmp
ソース