Which udev rules get executed for USB device?

Question

I am new to udev. I need to see which rules are executed for USB device plugged in to linux machine. Is there any logging provided by udev?

Answer 1

This is exactly what

udevadm trigger --verbose ...

will tell you. It'll trigger a re-evaluation of the udev rules and you can use the other flags such as --subsystem-match and --attr-match to narrow down your USB device.

man udevadm

And to find these attributes of your USB device use

lsusb -v

Answer 2

Try something like: udevadm test /dev/bus/usb/001/045

Answer 3

Carlqvist's answer is correct but it leaves out most of the details. From a real life case...

Problem: My USB Keyboard is working in my gNewsense setup but my SourceMage. So following is me trying to figure out what udev rules in gNewsense apply to this keyboard.

1) Get basic info

# lsusb
[...omitted...]
Bus 007 Device 006: ID 413c:2003 Dell Computer Corp. Keyboard
[...omitted...]

So now I know...

The USB device node (not the same as keyboard device) is /dev/bus/usb/007/006 The idVendor=413c and the idProduct=2003 And if the keyboard didn't have any logos or stamps I would have human friendly text to search on.

Nowadays, keyboard and mice are under /dev/input/*, this is just something you have to know or gleem from webpages. I got lucky and there is /dev/input/by-id/usb-Dell_Dell_USB_Keyboard-event-kbd

Which in my case is a sym link to /dev/input/event0

2) This will get the 'other' device path (kernel or udev internal) for the keyboard

# udevadm info --query=path --name=/dev/input/by-id/usb-Dell_Dell_USB_Keyboard-event-kbd
/devices/pci0000:00/0000:00:1d.1/usb7/7-1/7-1:1.0/input/input9/event0

3) Now, what rules happened to make this keyboard work?

Note that grep'ing for the idVendor and idProduct may be enough but there are typically wild cards and default builtin cases that do most of the work.

The udevadm test command will tell you all the rules, in the order that they are handled during this event (the event of plugging the USB keyboard into the USB connector).

Lines starting with parse_file show you the rules scripts files that actually got hooked into (e)udev in the order that they got read (lower number prefix should be first). This is normally is a crap ton files, so ignore them for now.

Lines starting with udev_node_mknod are of interest because that's when udev actually makes the device node.

Lines startings with udev_rules_apply_to_event are probably what you're interested in. It give the rule script file and the line number of rule triggering some change in udev.

So here is my output. There will be a lot of noise (which I have omitted) but you can still trace through and see the creation of the dev nodes

# udevadm test /devices/pci0000:00/0000:00:1d.1/usb7/7-1/7-1:1.0/input/input9/event0
[...]
parse_file: reading '/lib/udev/rules.d/69-cd-sensors.rules' as rules file
add_rule: IMPORT found builtin 'usb_id', replacing /lib/udev/rules.d/69-cd-sensors.rules:78
[...]
udev_rules_apply_to_event: IMPORT builtin 'input_id' /lib/udev/rules.d/50-udev-default.rules:4
[...]
udev_builtin_add_property: ID_INPUT_KEY=1
udev_builtin_add_property: ID_INPUT_KEYBOARD=1
[...]
udev_rules_apply_to_event: IMPORT builtin 'usb_id' /lib/udev/rules.d/60-persistent-input.rules:7
builtin_usb_id: /sys/devices/pci0000:00/0000:00:1d.1/usb7/7-1/7-1:1.0: if_class 3 protocol 0
udev_builtin_add_property: ID_VENDOR=Dell
udev_builtin_add_property: ID_VENDOR_ENC=Dell
udev_builtin_add_property: ID_VENDOR_ID=413c
udev_builtin_add_property: ID_MODEL=Dell_USB_Keyboard
udev_builtin_add_property: ID_MODEL_ENC=Dell\x20USB\x20Keyboard
udev_builtin_add_property: ID_MODEL_ID=2003
[...]
udev_rules_apply_to_event: LINK 'input/by-id/usb-Dell_Dell_USB_Keyboard-event-kbd' /lib/udev/rules.d/60-persistent-input.rules:24
udev_rules_apply_to_event: IMPORT builtin 'path_id' /lib/udev/rules.d/60-persistent-input.rules:31
udev_builtin_add_property: ID_PATH=pci-0000:00:1d.1-usb-0:1:1.0
udev_builtin_add_property: ID_PATH_TAG=pci-0000_00_1d_1-usb-0_1_1_0
udev_rules_apply_to_event: LINK 'input/by-path/pci-0000:00:1d.1-usb-0:1:1.0-event-kbd' /lib/udev/rules.d/60-persistent-input.rules:33
udev_rules_apply_to_event: IMPORT builtin skip 'usb_id' /lib/udev/rules.d/95-keymap.rules:13
udev_event_execute_rules: no node name set, will use kernel supplied name 'input/event0'
udev_node_add: creating device node '/dev/input/event0', devnum=13:64, mode=01600, uid=0, gid=0
udev_node_mknod: preserve file '/dev/input/event0', because it has correct dev_t
udev_node_mknod: preserve permissions /dev/input/event0, 021600, uid=0, gid=0
node_symlink: preserve already existing symlink '/dev/char/13:64' to '../input/event0'
link_find_prioritized: found 'c13:64' claiming '/run/udev/links/input\x2fby-id\x2fusb-Dell_Dell_USB_Keyboard-event-kbd'
link_update: creating link '/dev/input/by-id/usb-Dell_Dell_USB_Keyboard-event-kbd' to '/dev/input/event0'
node_symlink: preserve already existing symlink '/dev/input/by-id/usb-Dell_Dell_USB_Keyboard-event-kbd' to '../event0'
link_find_prioritized: found 'c13:64' claiming '/run/udev/links/input\x2fby-path\x2fpci-0000:00:1d.1-usb-0:1:1.0-event-kbd'
link_update: creating link '/dev/input/by-path/pci-0000:00:1d.1-usb-0:1:1.0-event-kbd' to '/dev/input/event0'
node_symlink: preserve already existing symlink '/dev/input/by-path/pci-0000:00:1d.1-usb-0:1:1.0-event-kbd' to '../event0'
udev_device_update_db: created db file '/run/udev/data/c13:64' for '/devices/pci0000:00/0000:00:1d.1/usb7/7-1/7-1:1.0/input/input9/event0'
.INPUT_CLASS=kbd
ACTION=add
[...]
[end]