How to reload udev rules without reboot?

Question

How should one reload udev rules, so that newly created one can function?

I'm running Arch Linux, and I don't have a udevstart command here.

Also checked /etc/rc.d, no udev service there.

Please note that more recent versions of udev have dropped the inotify support so the reloading of the rules on change is needed more often these days. — Colin Guthrie, Feb 10 '13 at 14:49

score 423 · Accepted Answer · edited Mar 30 '17 at 16:38

423

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

edited Mar 30 '17 at 16:38

Ross Rogers

109

answered May 26 '12 at 00:59

Ignacio Vazquez-Abrams

45,725

4

Do you need udevtrigger afterwards? – Nils May 26 '12 at 20:28
44

@Nils Actually, you may need udevtrigger (or rather udevadm trigger on most distributions) instead (that, or plug the device out and back it). --reload-rules is almost always useless as it happens automatically. – Gilles 'SO- stop being evil' Mar 05 '13 at 10:28
13

udevadm trigger did the trick on CentOS 6 for me. – astrostl Aug 07 '13 at 18:19
3

udevtrigger or udevadm trigger did not work for me. I found some devices will work after unloading and loading the module for the same (assuming it is loadable module). What I found out is one does not necessarily have to reboot the system. Example for a network device, I do rmmod ixgbe, rmmod tg3,rmmod e1000 then modprobe ixgbe, modprobe tg3,modprobe e1000 depending on type of network driver. – enthusiasticgeek Jan 22 '15 at 20:25
1

Neither of things mentioned among the answers worked for me on Debian Jessie (8.0). The thing which worked is ip link set $oldname name $newname mentioned here. In my case, I needed to replace an iface named lan with a bridged iface (for KVM), and hence the original--now underlying--iface had to get its old name, eth1, back. So the trick was: 1) bring iface down; 2) fix network config up; 3) update udev naming rules file; 4) rename the iface using ip link...; 5) bring the bridge up. – kostix Mar 20 '15 at 15:53
1

Don't forget, you may need to unplug and plug the device back in to load the new rules for it. – Eric Fossum Apr 24 '15 at 14:44
for remote pcs and usb disks: modprobe -r usb_storage ; modprobe usb_storage – Lluís Aug 26 '15 at 10:22
6

I did have to sudo udevadm trigger after this, though removing the sudo didn't show any error, I didn't actually see any change until I ran it w/ sudo – Jacob Minshall Nov 10 '15 at 17:43
On Debian testing 'udevadm trigger' does not work. I had to unplug and plug usb ethernet card only then udev triggered new rule. – Trismegistos Jun 06 '17 at 12:55
1

I required sudo udevadm trigger instead of udevadm trigger as well. See my comments under this answer here: https://askubuntu.com/questions/1048870/permission-denied-to-non-root-user-for-usb-device/1187646#1187646. Doing it with sudo took ~2 sec, but doing it withOUT sudo took only ~0.2 sec. So clearly they are not doing the same thing for me. – Gabriel Staples Feb 17 '20 at 04:21
@JacobMinshall, if you or anyone else confirms sudo is in fact required, as I think it is, here's an answer for that to be upvoted to indicate that: https://unix.stackexchange.com/questions/39370/how-to-reload-udev-rules-without-reboot/567996#567996. – Gabriel Staples Feb 17 '20 at 04:30
For some reason, sudo udevadm test /sys/bus/net/can0 (change for your device), triggered device renaming for me. – thomasa88 Jun 02 '21 at 11:24
$ sudo udevadm control --reload is all that is needed. – Jim Fell May 23 '22 at 21:50
Note that udevadm trigger performs a udev "change". If you want to trigger an "add", or if you want to be more specific, check out @mbadmin 's answer. – Mike S Apr 11 '23 at 13:26

Gilles 'SO- stop being evil' · Answer 2 · 2019-07-25T12:53:21.003

90

Udev uses the inotify mechanism to watch for changes in the rules directory, in both the library and in the local configuration trees (typically located at /lib/udev/rules.d and /etc/udev/rules.d). So most of the time you don't need to do anything when you change a rules file.

You only need to notify the udev daemon explicitly if you're doing something unusual, for example if you have a rule that includes files in another directory. Then you can use the usual convention for asking daemons to reload their configuration: send a SIGHUP (pkill -HUP udevd). Or you can use the udevadm command: udevadm control --reload-rules.

However, beware that different versions of udev have historically had different triggers for reloading the rules automatically. So if in doubt, call udevadm control --reload-rules: it won't do any harm anyway.

The udev rules are only applied when a device is added. If you want to reapply the rules to a device that is already connected, you need to do this explicitly, by calling udevadm trigger with the right options to match the device(s) whose configuration has changed, e.g. udevadm trigger --attr-match=vendor='Yoyodyne' --attr-match=model='Frobnicator 300'.

edited Jul 25 '19 at 12:53

answered May 28 '12 at 00:55

Gilles 'SO- stop being evil'

829,060

1

Does systemd udev use inotify to watch for rule changes? – Craig McQueen May 19 '16 at 02:28
The inotify mechanism does not always catch a change of a udev rule file. For example when I use cat > 10-name.rules to change the rule file by pasting the contents, I have to reload rules manually using udevadm. Tested on Raspbian Stretch. – Daniel K. Jul 25 '19 at 08:55
@DanielK. Has this changed recently? IIRC I checked both a systemd udev and a non-systemd udev when I posted this answer, and both did use inotify, so --reload-rules was only needed in uncommon cases. – Gilles 'SO- stop being evil' Jul 25 '19 at 11:17
@Gilles: maybe my example above (overwriting an existing rule file using shell redirection) can be considered being an "uncommon case". When I modified this file by way of an editor, e.g., vi, the inotify mechanism worked. – Daniel K. Jul 25 '19 at 12:43
@DanielK. Ah, that's good to know. It isn't an uncommon case: some editors would save the file by rewriting (with Vim and Emacs, it depends how they're configured). Weird that udev only handles one of the cases — it looks like a bug to me, because I can't think of a reason to treat them differently. – Gilles 'SO- stop being evil' Jul 25 '19 at 12:51

score 26 · Answer 3 · edited Mar 18 '16 at 13:34

26

I'm adding this because some day I will need it... again.

Sometimes you get an incorrect matching of ethernet device numbers and MAC addresses. Sometimes this is really important, like when running in a VM and each device is assigned to a different VLAN.

Bring the network interfaces down, then
modify /etc/udev/rules.d/70-persistent-net.rules (or its equivalent)
re-load with udevadm control --reload-rules
re-trigger with udevadm trigger --attr-match=subsystem=net
bring the network interfaces up.

I was surprised how well this worked.

edited Mar 18 '16 at 13:34

Otheus

6,138

answered Feb 21 '14 at 13:51

Otheus

261

6

on Red Hat: service network stop && udevadm control --reload-rules; udevadm trigger --attr-match=subsystem=net; service network start – Alexander Torstling Feb 19 '15 at 12:40
1

On Debian testing 'udevadm trigger --attr-match=subsystem=net' does not work. I had to unplug and plug usb ethernet card only then udev triggered new rule. – Trismegistos Jun 06 '17 at 12:55
I'd be willing to bet, Trismegistos, that the unplug/plug is akin to removing and reloading the network driver, as per Clayton Dukes' answer. – Mike S Nov 28 '17 at 23:58

score 15 · Answer 4 · edited Jun 21 '15 at 20:01

15

I am not sure if this applies, and this is definitely an older post but it came up pretty high my web search for udev info so I thought I might share some knowledge.

You can trigger udev rules manually for specific devices. This applies only to redhat-related distros (centos fedora etc etc etc)

Once you make the relevant changes in your rules file (/etc/udev/rules.d/whateveryoucalledyourrules), you can echo change in to the device's uevent.

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

This will force a udev rule reading for ONLY this device. Much better, and more targeted in my opinion.

edited Jun 21 '15 at 20:01

user.dz

1,875

answered Jun 10 '15 at 00:11

mbadmin

151

This is great. I did a echo add > /sys/devices/pci0000\:d7/0000\:d7\:00.0/0000\:d8\:00.0/uevent so I can tell you that it works for non-block devices, as well, and it works to trigger "add" events. – Mike S Apr 11 '23 at 13:26

score 4 · Answer 5 · edited Jun 13 '16 at 15:39

For me, below command sequence has worked as it is desired.

I have done modifications in /etc/udev/rules.d/70-persistent-net.rules to change the eth number and to reload them without rebooting.

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

By following this, It was successfully loaded in run time without rebooting the machine.

Any suggestion or recommendations on this are welcome, as I have discovered this on my own by reading the man pages.

score 3 · Answer 6 · answered Jun 22 '17 at 19:41

I'm adding the correct answer here because it took me a while to notice it in the comment from @enthusiasticgeek. All you need to do (assuming you are on the console of the server - clearly this is bad to do if you are ssh'd in!):

Get a list of the interface module(s) being used:

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

In my case, it's igb, so it prints just that.

type sudo rmmod igb (replace igb with your card driver obtained from step 1.

next, edit /etc/udev/rules.d/70-persistent-net.rules as needed, then load the module again using modprobe igb, again replacing igb with yours.

This, combined with Otheus' answer, was the secret sauce that enabled me to fix my Mellanox network card config without a machine reboot. I believe the loading of the driver and the udevadm read of the persistent-net.rules file is roughly akin to what the system does when it's booting. — Mike S, Nov 29 '17 at 00:00

score 1 · Answer 7 · answered Feb 17 '20 at 04:28

1

This is a slight change from the main answer: sudo seemed to be required for me on both commands.

Anecdotal evidence: doing sudo udevadm trigger took ~2 sec, but doing it withOUT sudo took only ~0.2 sec. So clearly they are not doing the same thing for me. Do this instead:

sudo udevadm control --reload-rules
sudo udevadm trigger

And then lastly (per the 2nd link below), unplug your device and plug it back in.

References:

See comments under both of the answers above as well.

answered Feb 17 '20 at 04:28

Gabriel Staples

2,562

4

The commands in Igancio's answer have # as prompt which implies that they need to be executed as root. Depending on your preference you then may use sudo or just execute them in a root shell (which you may enter by e.g. su - or sudo -s or just log into another console as root). – maxschlepzig May 24 '20 at 11:43
Ahhh. That's subtle. I had no idea. Thanks. – Gabriel Staples May 24 '20 at 16:18

score 0 · Answer 8 · answered Jul 31 '19 at 11:47

in case of multiple networks

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

How to reload udev rules without reboot?

8 Answers8

References:

Linked