Under what conditions should the 'start_udev' command be run?

surroundings

• Red Hat Enterprise Linux

problem

• We run start_udev as part of the storage allocation procedure that we have. It works, but it can be disruptive if an oracle DB instance is up and running (the listener interfaces briefly disappear). Our RH versions that we certified for SAN are 4u5, 4u8, 5.4 and 5.5.

• If we don't run it, we don't get the multipath aliases show up in /dev/mapper directory - just the WWIDs.

• The SAN folks want to know under what circumstances should start_udev be run?

resolution

• Nobody should ever run start_udev, only rc.sysinit should call start_udev.

RHEL6

• If one has made a change and you don't want to reboot the system then can utilize udevadm trigger instead. Specify --type and --action or it will effectively work like start_udev.

 # /sbin/udevadm trigger --type=subsystems --action=add
 # /sbin/udevadm trigger --type=devices --action=add

　　

 # /sbin/udevadm trigger --type=subsystems --action=change
 # /sbin/udevadm trigger --type=devices --action=change

• One can even trigger only specific devices like below;

 # echo change > /sys/block/sda/sda1/uevent

　　

RHEL5

• To test the rule, use the udevtest command like so:

[root@rhel5 rules.d]# udevtest /block/sdc | grep mydevice
udev_rules_get_name: add symlink 'mydevice'
udev_node_add: creating symlink '/dev/mydevice' to 'sdc'

• If /dev/sdc has partitions on it, run this command to test a device will be created for /dev/sdc1:

[root@rhel5 rules.d]# udevtest /block/sdc/sdc1 | grep mydevice
udev_rules_get_name: add symlink 'mydevice1'
udev_node_add: creating symlink '/dev/mydevice1' to 'sdc1'

Note: If an old udev package is installed, the symbolic link for each partition might not be created. In such a case, it should be added one more line which uses "all_partitions" option to the rule file:

KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -u -s %p", RESULT=="3600a0b800013275100000015427b625e", SYMLINK{all_partitions}+="mydevice%n"

• Finally, echo change into the underlying device's uevent directory to have udev create the device(s):

[root@rhel5 rules.d]# echo change > /sys/block/sdc/uevent
[root@rhel5 rules.d]# echo change > /sys/block/sdc/sdc1/uevent

• Verify that the device(s) /dev/mydevice have been created and are symbolic links to to /dev/sdc.
• As long as the device with the unique identifier 3600a0b800013275100000015427b625e is attached/visible to Red Hat Enterprise Linux, it will always be statically bound to the name /dev/mydevice by udev.

source

• Here are some under the hood operations of start_udev which demonstrate the danger of running the start_udev command on a running production system.

  • start_udev copies the whole contents of /etc/udev/devices /lib/udev/devices to /dev, overwriting any modifications like permissions
  • start_udev kills the udevd daemon and restarts it, which could interrupt all currently processed udev events
  • start_udev triggers all devices on the system, so all disks are queried again, which causes heavy I/O, and some permissions might be reset
  • start_udev runs /sbin/restorecon, which resets all selinux labels in /dev