316

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.

Improve this question
3
  • 2
    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, 2013 at 14:49
  • What is udev? Is it the manager of /dev ?
    – Sandburg
    Sep 17, 2018 at 12:51
  • 1
    @Sandburg yes it handles plug-n-play on Linux systems.
    – Aaron D. Marasco
    Mar 26, 2019 at 21:01

8 Answers 8

Reset to default
399 
# udevadm control --reload-rules && udevadm trigger
Improve this answer
14
  • 4
    Do you need udevtrigger afterwards?
    – Nils
    May 26, 2012 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 5, 2013 at 10:28
  • 13
    udevadm trigger did the trick on CentOS 6 for me.
    – astrostl
    Aug 7, 2013 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, 2015 at 20:25
  • 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, 2015 at 17:43
87

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

Improve this answer
5
  • 1
    Does systemd udev use inotify to watch for rule changes?
    – Craig McQueen
    May 19, 2016 at 2: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, 2019 at 8: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, 2019 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, 2019 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, 2019 at 12:51
25

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.

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

I was surprised how well this worked.

Improve this answer
3
  • 6
    on Red Hat: service network stop && udevadm control --reload-rules; udevadm trigger --attr-match=subsystem=net; service network start
    – Alexander Torstling
    Feb 19, 2015 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 6, 2017 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, 2017 at 23:58
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.

Improve this answer
1
  • 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 at 13:26
4

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.

Improve this answer
3

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!):

  1. 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.

  1. 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.

Improve this answer
1
  • 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, 2017 at 0:00
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:

  1. How to reload udev rules without reboot?
  2. 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.

Improve this answer
2
  • 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, 2020 at 11:43
  • Ahhh. That's subtle. I had no idea. Thanks.
    – Gabriel Staples
    May 24, 2020 at 16:18
0

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
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .