How to find reasons why an udev rule is not applied?

Question

I added an udev rule to generate a separate link to a special tty device. I took the vendor and product id from lsusb:

Bus 001 Device 016: ID abcd:1234 Foo Device

The dmesg output for the device is:

[  369.384850] usb 1-1.1: new full-speed USB device number 4 using xhci_hcd
[  369.470492] usb 1-1.1: New USB device found, idVendor=09d8, idProduct=0420
[  369.470506] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  369.470515] usb 1-1.1: Product: TWN4/B1.06/CCL3.12/PRS1.04
[  369.470522] usb 1-1.1: Manufacturer: OEM
[  369.475188] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device

Normally the Debian system generates an ACM* tty for this device:

$ ls /dev/ttyACM*
/dev/ttyACM0

So I created /ect/udev/rules.d/99-bizrfid.rules:

ACTION=="add", ATTRS{idVendor}=="09d8", ATTRS{idProduct}=="0420", SYMLINK+="ttyMyDevice"

But ls /dev/tty* does not show ttyMyDevice.

What I tried so far without success:

1. Running udevadm trigger. This should apply the new udev rule.
2. I did a reboot.
3. I had a look to udevadm test /dev/ttyACM0. My udevrule is shown at the end. So I am sure that it had not been overridden. But I wonder about the 'unable to open' hint. Nevertheless this hint is present for other ttys, such as tty0 or ttyS0, too.

...    
Reading rules file: /lib/udev/rules.d/98-systemd.rules
Reading rules file: /etc/udev/rules.d/99-bizrfid.rules
rules contain 49152 bytes tokens (4096 * 12 bytes), 12883 bytes strings
4240 strings (40079 bytes), 3515 de-duplicated (27922 bytes), 726 trie nodes used
unable to open device '/sys/dev/ttyACM0'
Unload module index
Unloaded link configuration context.

4. I reconnected the USB device.
5. I tried another udev rule. This rule is 100% correct because I use this rule already fo other devices. But it does not work for the ttyACM0:

ACTION=="add", KERNEL=="ttyACM*", MODE="0666"

I wonder why this is not working. How to find reasons why an udev rule is not applied?

Mirepoix

Could you share with us the valid part of dmesg output? It =would help us also what kind of USB device it is and actual values. – Piccard

@tukan: Good Idea! I added the dmesg output. – Mirepoix

Thanks. Now what driver do you use? Do you have a generic one or you have a custom compiled one? The reason why I'm asking is that if you check - usb.ids I don't see your idVendor=09d8, idProduct=0420 supported. – Piccard

dmesg says I am using the cdc_acm driver. I is NOT a custom compiled one. – Mirepoix

Ok. If you do udevadm test -a add $(udevadm info -q path -n /dev/ttyACM0) what is returned? – Piccard

One more thing came into my mind. Are you (username) member of dialup and tty group? – Piccard

Do you need to add SUBSYSTEM="usb"? – Phellem

@stark: The SUBSYSTEM="usb" did not work. – Mirepoix

@Piccard I added the output as an example within the answer but I cannot see any issues. I do not understand the importanve of the member/group. I am logged in as root and udevadm is being run as root. Should root be member of dialup? – Mirepoix

You should add the information to your question, not as answer to your question. Ah, you are running as root, then it should be ok. The reason is Invalid rule /etc/udev/rules.d/99-bizrfid.rules:1: invalid ACTION operation. Please show us the actual 99-bizrfid.rules rule not a stub as you did in your question. – Piccard

The question is "How to find reasons...". Therefore, I put together solutions to find the problems. I think this matches to the question. – Mirepoix

@Piccard Thank you so much for your help. A added now a cat of 99.bizrfid.rules. It is nearly the same. The "Invalid rule..." error occured because I tried something else this morning and forgot an =. The rule is now really the same as quoted and I updated the output of the udevadm test.... Sorry for that confusion. – Mirepoix

You are welcome. The answers are reserved for answer to the question. Since you are adding information it should not be considered an answer, but adding more information so we could answer your question. – Piccard

@Phellem it's SUBSYSTEM=="tty". – Elka

Answer 1

For the udev rule /ect/udev/rules.d/99-bizrfid.rules I would add the SUBSYSTEM:

ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="09d8", ATTRS{idProduct}=="0420", SYMLINK+="ttyMyDevice"

You could add also ATTRS{manufacturer}==, but idVendor and idProduct are sufficient.

Otherwise it looks correct and the test run creates the symlink:

creating link '/dev/ttyMyDevice' to '/dev/ttyACM0'

Piccard

Great! This works! But running udevadm trigger was not enough. I needed to run udevadm trigger and udevadm test -a add .... Or a full reboot. How did you found the reason why the udev rule was not applied? – Mirepoix

@Mirepoix Great ;). yes, udevadm trigger is not enough. You need to add the rule or most people do restart afterwards. How did I find it out? I would say experience and ruling out all other possibilities. For such linux/unix based questions you will find better suited unix stackexchange. Please don't forget to accept it - Accepting answers. – Piccard

If udevadm trigger doesn't work, it's not a solution. Something else is still wrong… – Elka

@Elka He had written the rule incorrectly. If it works after reboot? Why it should be wrong? – Piccard

Because you need a reboot. It's against Unix way. – Elka

@Elka Ok, I can understand that on server, but on a notebook? Not really. Anyways, you can use udevadm ... add and it works without reboot. You are complaining without substance, please provide a better solution or just go solve some other issue. – Piccard

Maybe udevadm control --reload should be executed before doing udevadm trigger, I usually run those two commands when modifying udev rules. But that's just a thought. Also, maybe try to reconnect your USB devices after doing those rules changes, anyway that would be my first instinct. And of course @Elka is right, in Linux you shouldn't reboot to make such small changes, some restart commands usually will do just fine. – Attenweiler

@SamProtsenko The OP said it works for him. His udev rule was incorrect, which was the core of the issue. As for the reboot, I was talking about one time reboot needed to see if everything works (if needed), of course, I'm not talking about rebooting every time you plug-in USB. It is always best to have it without reboot, but if it is on dev notebook (again talking about one-time reboot) I don't care as I have reboot done around 5-10s. On production server it is completely different issue, but you should not experiment with udev rules on such machine. – Piccard

Answer 2

According to the comments I the following can be tried to debug the problem:

Check the driver

Use dmesg to check the driver you are using and ensure that it is a generic one. If it is a custom compiled one, the problem could be inside your custom implementation. If it is a generic one, go on to step two. I found the driver name in the last line: cdc_acm

[  369.384850] usb 1-1.1: new full-speed USB device number 4 using xhci_hcd
[  369.470492] usb 1-1.1: New USB device found, idVendor=09d8, idProduct=0420
[  369.470506] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  369.470515] usb 1-1.1: Product: TWN4/B1.06/CCL3.12/PRS1.04
[  369.470522] usb 1-1.1: Manufacturer: OEM
[  369.475188] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device

Check the user permissions

Ensure that the permission of your udev rule is correct:

chmod 644 99-myrule.rules
chown root:root 99-myrule.rules

Do a test run for the add-action

Check the output of udevadm test -a add $(udevadm info -q path -n /dev/ttyACM0). My output looks like this:

calling: test

version 232
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

=== trie on-disk ===
tool version:          232
file size:         8447696 bytes
header size             80 bytes
strings            1849040 bytes
nodes              6598576 bytes
Load module index
Found container virtualization none
timestamp of '/etc/systemd/network' changed
timestamp of '/usr/lib/systemd/network' changed
timestamp of '/lib/systemd/network' changed
Parsed configuration file /lib/systemd/network/99-default.link
Created link configuration context.
timestamp of '/etc/udev/rules.d' changed
Skipping overridden file: /lib/udev/rules.d/99-bizrfid.rules.
Reading rules file: /lib/udev/rules.d/50-firmware.rules

...

Reading rules file: /lib/udev/rules.d/98-systemd.rules
Reading rules file: /etc/udev/rules.d/99-bizrfid.rules
rules contain 49152 bytes tokens (4096 * 12 bytes), 12900 bytes strings
4244 strings (40114 bytes), 3517 de-duplicated (27942 bytes), 728 trie nodes used
GROUP 20 /lib/udev/rules.d/50-udev-default.rules:26
IMPORT builtin 'hwdb' /lib/udev/rules.d/60-serial.rules:7
IMPORT builtin 'usb_id' /lib/udev/rules.d/60-serial.rules:8
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1/1-1.1:1.0: if_class 2 protocol 0
IMPORT builtin 'hwdb' /lib/udev/rules.d/60-serial.rules:8
IMPORT builtin 'path_id' /lib/udev/rules.d/60-serial.rules:15
LINK 'serial/by-path/pci-0000:00:14.0-usb-0:1.1:1.0' /lib/udev/rules.d/60-serial.rules:16
IMPORT builtin skip 'usb_id' /lib/udev/rules.d/60-serial.rules:19
LINK 'serial/by-id/usb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00' /lib/udev/rules.d/60-serial.rules:23
LINK 'ttyMyDevice' /etc/udev/rules.d/99-bizrfid.rules:1
handling device node '/dev/ttyACM0', devnum=c166:0, mode=0660, uid=0, gid=20
preserve permissions /dev/ttyACM0, 020660, uid=0, gid=20
preserve already existing symlink '/dev/char/166:0' to '../ttyACM0'
found 'c166:0' claiming '/run/udev/links/\x2fserial\x2fby-id\x2fusb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00'
creating link '/dev/serial/by-id/usb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00' to '/dev/ttyACM0'
preserve already existing symlink '/dev/serial/by-id/usb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00' to '../../ttyACM0'
found 'c166:0' claiming '/run/udev/links/\x2fserial\x2fby-path\x2fpci-0000:00:14.0-usb-0:1.1:1.0'
creating link '/dev/serial/by-path/pci-0000:00:14.0-usb-0:1.1:1.0' to '/dev/ttyACM0'
preserve already existing symlink '/dev/serial/by-path/pci-0000:00:14.0-usb-0:1.1:1.0' to '../../ttyACM0'
creating link '/dev/ttyMyDevice' to '/dev/ttyACM0'
creating symlink '/dev/ttyMyDevice' to 'ttyACM0'
created db file '/run/udev/data/c166:0' for '/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1/1-1.1:1.0/tty/ttyACM0'
ACTION=add
DEVLINKS=/dev/serial/by-path/pci-0000:00:14.0-usb-0:1.1:1.0 /dev/serial/by-id/usb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00 /dev/ttyMyDevice
DEVNAME=/dev/ttyACM0
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1/1-1.1:1.0/tty/ttyACM0
ID_BUS=usb
ID_MODEL=TWN4_B1.06_CCF3.00_PRS1.04
ID_MODEL_ENC=TWN4\x2fB1.06\x2fCCF3.00\x2fPRS1.04
ID_MODEL_FROM_DATABASE=Atom Processor Z36xxx/Z37xxx, Celeron N2000 Series USB xHCI
ID_MODEL_ID=0420
ID_PATH=pci-0000:00:14.0-usb-0:1.1:1.0
ID_PATH_TAG=pci-0000_00_14_0-usb-0_1_1_1_0
ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
ID_PCI_INTERFACE_FROM_DATABASE=XHCI
ID_PCI_SUBCLASS_FROM_DATABASE=USB controller
ID_REVISION=0200
ID_SERIAL=OEM_TWN4_B1.06_CCF3.00_PRS1.04
ID_TYPE=generic
ID_USB_CLASS_FROM_DATABASE=Communications
ID_USB_DRIVER=cdc_acm
ID_USB_INTERFACES=:020201:0a0000:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=OEM
ID_VENDOR_ENC=OEM
ID_VENDOR_FROM_DATABASE=Intel Corporation
ID_VENDOR_ID=09d8
MAJOR=166
MINOR=0
SUBSYSTEM=tty
TAGS=:systemd:
USEC_INITIALIZED=71480300178
Unload module index
Unloaded link configuration context.

Mirepoix