ANBOB™

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.

The udev man page describes the watch and nowatch options for ‘inotify’:

$ man udev
[...]
   watch
       Watch the device node with inotify, when closed after being opened for writing, a change uevent will be synthesised.

   nowatch
       Disable the watching of a device node with inotify.
[...]

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.

How to reload udev rules without reboot?

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

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

Check if the device is still listed

ls /dev/sd*

Verify the device is gone physically

lsblk
fdisk -l

Remove udev device manually (if still showing)

Use echo 1 > /sys/block/sdX/device/delete to tell the kernel the device is gone.
— or
rm /dev/sdX

Manual rm of /dev/sdX usually won’t help unless the kernel already dropped it.

Reload udev rules (if you’re debugging udev rules)

udevadm control --reload-rules

Trigger udev cleanup

udevadm trigger
-- or 
udevadm trigger --action=change
-- or
$ /sbin/udevadm trigger --type=devices --action=change

you can echo change in to the device’s uevent

[root@db1 dev]# ls -l asm*
lrwxrwxrwx 1 root root 3 Apr 19 22:01 asm_disk1 -> sdb
lrwxrwxrwx 1 root root 3 Apr 19 22:01 asm_ocr1 -> sdc
lrwxrwxrwx 1 root root 3 Apr 19 22:01 asm_ocr2 -> sde
lrwxrwxrwx 1 root root 3 Apr 19 22:01 asm_ocr3 -> sdd

[root@db1 dev]# date
Sat Apr 19 22:01:58 CST 2025

[root@db1 dev]# udevadm trigger
[root@db1 dev]# ls -l asm*
lrwxrwxrwx 1 root root 3 Apr 19 22:02 asm_disk1 -> sdb
lrwxrwxrwx 1 root root 3 Apr 19 22:02 asm_ocr1 -> sdc
lrwxrwxrwx 1 root root 3 Apr 19 22:02 asm_ocr2 -> sde
lrwxrwxrwx 1 root root 3 Apr 19 22:02 asm_ocr3 -> sdd


[root@db1 dev]# date
Sat Apr 19 22:03:43 CST 2025
[root@db1 dev]# echo change > /sys/block/sde/uevent
[root@db1 dev]# ls -l asm*
lrwxrwxrwx 1 root root 3 Apr 19 22:02 asm_disk1 -> sdb
lrwxrwxrwx 1 root root 3 Apr 19 22:02 asm_ocr1 -> sdc
lrwxrwxrwx 1 root root 3 Apr 19 22:03 asm_ocr2 -> sde
lrwxrwxrwx 1 root root 3 Apr 19 22:02 asm_ocr3 -> sdd

Udev rules are getting reloaded frequently and causing Oracle ASM outage
After installing tuned on system, we are getting high SYS CPU at specific times when the tuned-mpath-iosched rule is triggered from /lib/udev.

Diagnostic Steps

Monitoring the udev events using below commands showed that there were frequent 'change' events triggered for the devices and the rules were getting reloaded.
 
 $ udevadm monitor --property &>> /tmp/udevadm_monitor_property
 $ udevadm monitor --kernel &>> /tmp/udevadm_monitor_kernel
 $ udevadm monitor --udev &>> /tmp/udevadm_monitor_udev

The ‘nowatch’ option would only disable the ‘inotify’ watch events. The inotify API provides a mechanism for monitoring the filesystem events. It is used to monitor the individual files or to monitor directories. So, setting the ‘nowatch’ option for devices does not disable any existing device specific udev rules and any changes to underlying disk (e.g. add/remove/change) would still trigger the udev rules as expected.

It is recommended that the oracle nowatch options be placed within their own rules file separate from other Oracle rules and that the file number (’96’ in the above example) be larger than any other oracle rules file number. You can name the file whatever you want, as long as the lines inside the file match the nowatch rules above and that rules file is run later (has higher ordinal value) in the list of numbered udev rules to allow other oracle rules to load first. Typically the other oracle asm ownership and symlink rules are numbered in the 50s or 80s, but sometimes are numbered rule 99 (rules are executed in ordinal value 00-99). It that case, renumbering the existing asm ownership/symlink rules file to something like 95-98 and then the nowatch rules as number 99 would be recommended.

Here is an example of an open test case with no write triggering the rule

./check_udev /dev/mapper/mpathmn
 Opened file /dev/mapper/mpathmn with descriptor 3

KERNEL[1433182713.102117] change   /devices/virtual/block/dm-1 (block)
UDEV  [1433182713.823458] change   /devices/virtual/block/dm-1 (block)

'check_udev.c' program used for binary 'check_udev':
 #include <stdio.h>
 #include <stdlib.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>

 int main(int argc, char*argv[])
 {
 int fd;
 fd=open(argv[1],O_RDWR,0660);
 printf("Opened file %s with descriptor %d\n",argv[1],fd);
 close(fd);
 }

Note:
Do not backup udev rule file  in udev role current directory(eg/lib/udev/rules.d and /etc/udev/rules.d)!.

打赏

微信扫一扫，打赏作者吧～