How to reload udev rules without reboot?
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.
# udevadm control --reload-rules && udevadm trigger
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'
.
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.
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.
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.
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
(replaceigb
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.
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
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:
- How to reload udev rules without reboot?
- https://askubuntu.com/questions/1048870/permission-denied-to-non-root-user-for-usb-device/1187646#1187646
See comments under both of the answers above as well.