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.
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community# udevadm control --reload-rules && udevadm trigger
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.
Mar 5, 2013 at 10:28
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.
Jan 22, 2015 at 20:25
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
Nov 10, 2015 at 17:43
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'
.
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.
Jul 25, 2019 at 8:55
--reload-rules
was only needed in uncommon cases.
Jul 25, 2019 at 11:17
inotify
mechanism worked.
Jul 25, 2019 at 12:43
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.
/etc/udev/rules.d/70-persistent-net.rules
(or its equivalent)udevadm control --reload-rules
udevadm trigger --attr-match=subsystem=net
I was surprised how well this worked.
service network stop && udevadm control --reload-rules; udevadm trigger --attr-match=subsystem=net; service network start
Feb 19, 2015 at 12:40
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.
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.
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!):
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.
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 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.
See comments under both of the answers above as well.
#
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).
May 24, 2020 at 11:43
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
udev
? Is it the manager of/dev
?