2

When I plug in a usb-to-serial device, it takes some time for the device to be switched to the "dialout" group (it starts out in the "root") group. This wreaks havoc with some client software that expects to have permissions to read the device immediately after reset.

I tried two usb-to-serial devices and they both have the same behavior - atmega32u4 and ch340.

Here is what happens if I print ls -l /dev/tty* in a rapid loop:

The first time I plug in the device:

> while ((1)); do ls -l /dev/ttyACM* 2> /dev/null; sleep 0.1; done;
# it does not print anything until I plug in the device
crw-rw-rw- 1 root dialout 166, 0 Aug 19 17:23 /dev/ttyACM0
crw-rw-rw- 1 root dialout 166, 0 Aug 19 17:23 /dev/ttyACM0
crw-rw-rw- 1 root dialout 166, 0 Aug 19 17:23 /dev/ttyACM0

This looks great, but then this happens when I unplug and plug in the device again:

> while ((1)); do ls -l /dev/ttyACM* 2> /dev/null; sleep 0.1; done;
# Nothing is printed out until I plug the device in for a second time
crw------- 1 root root 166, 0 Aug 19 17:23 /dev/ttyACM0
crw------- 1 root root 166, 0 Aug 19 17:23 /dev/ttyACM0
crw------- 1 root root 166, 0 Aug 19 17:23 /dev/ttyACM0
crw------- 1 root root 166, 0 Aug 19 17:23 /dev/ttyACM0
crw------- 1 root root 166, 0 Aug 19 17:23 /dev/ttyACM0
crw-rw-rw- 1 root dialout 166, 0 Aug 19 17:23 /dev/ttyACM0
crw-rw-rw- 1 root dialout 166, 0 Aug 19 17:23 /dev/ttyACM0
crw-rw-rw- 1 root dialout 166, 0 Aug 19 17:23 /dev/ttyACM0

After the first time the device was plugged in, on all consecutive attempts to plug it in, I have the device appear in group "root" for half a second before it moves itself to group "dialout". Can this be made instantaneous?

The dmesg messages for the first and for the consecutive plugging-ins were the same.

This happens both without any custom udev rules, and with a udev rule asking for this specific device to be put in group "dialout" - there is always a half second delay after the first time it was plugged in.

This is on Debian Unstable from August 2018.

Here is what udevadm monitor shows:

sudo udevadm monitor & (while ((1)); do ls -l /dev/ttyACM*; ls -l /dev/ttyUSB*; sleep 0.1; done;) 2> /dev/null
[1] 18788
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[8916.515599] add      /devices/pci0000:00/0000:00:14.0/usb1/1-1 (usb)
KERNEL[8916.516088] add      /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0 (usb)
KERNEL[8916.516768] add      /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/tty/ttyACM0 (tty)
KERNEL[8916.516835] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0 (usb)
KERNEL[8916.516886] add      /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.1 (usb)
KERNEL[8916.516944] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.1 (usb)
KERNEL[8916.516999] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-1 (usb)
crw------- 1 root root 166, 0 Aug 19 17:54 /dev/ttyACM0
crw------- 1 root root 166, 0 Aug 19 17:54 /dev/ttyACM0
crw------- 1 root root 166, 0 Aug 19 17:54 /dev/ttyACM0
crw------- 1 root root 166, 0 Aug 19 17:54 /dev/ttyACM0
crw------- 1 root root 166, 0 Aug 19 17:54 /dev/ttyACM0
UDEV  [8917.063021] add      /devices/pci0000:00/0000:00:14.0/usb1/1-1 (usb)
UDEV  [8917.064210] add      /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0 (usb)
UDEV  [8917.068240] add      /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.1 (usb)
UDEV  [8917.068290] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.1 (usb)
UDEV  [8917.068359] add      /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/tty/ttyACM0 (tty)
UDEV  [8917.080062] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0 (usb)
UDEV  [8917.080134] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-1 (usb)
crw-rw-rw- 1 root dialout 166, 0 Aug 19 17:54 /dev/ttyACM0
crw-rw-rw- 1 root dialout 166, 0 Aug 19 17:54 /dev/ttyACM0
crw-rw-rw- 1 root dialout 166, 0 Aug 19 17:54 /dev/ttyACM0
  • Guess: Some other udev rule takes half a second to complete, and blocks the group-assigning udev rule during this time. Debugging udev-rules is a PITA. You can manually restart udevd with verbose messages enabled, though. That should give you some idea which rules are executed, and help finding rule that is the culprit. Another option is to couple the group change with symlink creation in a custom rule, and let your application fire on the symlink, not on /dev/ttyACM0. – dirkt Aug 20 '18 at 10:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.