1

I use Ubuntu 20.04 LTS and have wrote a custom udev rule in /etc/udev/rules.d/, which creates a symlink, called "mybackup" and wrotes a short message to syslog/journalctl, if a specific external USB hard drive is connected. My udev rule with the name 99-datensicherung.rules:

ENV{DEVTYPE}=="usb_device", \
SUBSYSTEM=="usb", \
ATTRS{idVendor}=="174c", \
ATTRS{idProduct}=="55aa", \
ATTRS{bcdDevice}=="0100", \
SYMLINK+="mybackup", \
ACTION=="add", \
RUN+="/usr/bin/logger MY DEVICE CONNECTED."

If I look into the syslog, I found the message of logger and see, that the symlink is created:

Okt 15 11:22:46 SWPITSLNB systemd-udevd[185107]: 2-4: /etc/udev/rules.d/99-datensicherung.rules:9 LINK 'mybackup'
Okt 15 11:22:46 SWPITSLNB systemd-udevd[185107]: 2-4: /etc/udev/rules.d/99-datensicherung.rules:9 RUN '/usr/bin/logger MY DEVICE CONNECTED.'
Okt 15 11:22:46 SWPITSLNB systemd-udevd[185107]: 2-4: Handling device node '/dev/bus/usb/002/055', devnum=c189:182
Okt 15 11:22:46 SWPITSLNB systemd-udevd[185107]: 2-4: Setting permissions /dev/bus/usb/002/055, uid=0, gid=0, mode=0664
Okt 15 11:22:46 SWPITSLNB systemd-udevd[185107]: 2-4: Creating symlink '/dev/char/189:182' to '../bus/usb/002/055'
Okt 15 11:22:46 SWPITSLNB systemd-udevd[185107]: 2-4: Creating symlink '/dev/mybackup' to 'bus/usb/002/055'

But a very short time later, the syslog tell me:

Okt 15 11:22:46 SWPITSLNB systemd-udevd[185107]: 2-4: /usr/lib/udev/rules.d/69-libmtp.rules:2685 Running PROGRAM 'mtp-probe /sys/devices/pci0000:00/0000:00:14.0/usb2/2-4 2 55'
Okt 15 11:22:46 SWPITSLNB systemd-udevd[185107]: 2-4: Starting 'mtp-probe /sys/devices/pci0000:00/0000:00:14.0/usb2/2-4 2 55'
Okt 15 11:22:46 SWPITSLNB systemd-udevd[185107]: Successfully forked off '(spawn)' as PID 185132.
Okt 15 11:22:46 SWPITSLNB mtp-probe[185132]: checking bus 2, device 55: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4"
Okt 15 11:22:46 SWPITSLNB mtp-probe[185132]: bus: 2, device: 55 was not an MTP device
Okt 15 11:22:46 SWPITSLNB systemd-udevd[185107]: 2-4: 'mtp-probe /sys/devices/pci0000:00/0000:00:14.0/usb2/2-4 2 55'(out) '0'
Okt 15 11:22:46 SWPITSLNB systemd-udevd[185107]: 2-4: Process 'mtp-probe /sys/devices/pci0000:00/0000:00:14.0/usb2/2-4 2 55' succeeded.
Okt 15 11:22:46 SWPITSLNB systemd-udevd[185107]: 2-4: Updating old name, '/dev/mybackup' no longer belonging to '/devices/pci0000:00/0000:00:14.0/usb2/2-4'
Okt 15 11:22:46 SWPITSLNB systemd-udevd[185107]: 2-4: No reference left, removing '/dev/mybackup'

How can I prevent the deletion of my symlink, from the other udev rule? Thank you very much!

Full syslog: https://pastebin.com/k5q1uuB0

4
  • Out of curiosity, if it's a disk (that I assume is going to be mounted as a block device), what's the use of a symlink to the raw USB device? Oct 15, 2021 at 10:11
  • @user1686 I had read it in multiple tutorials and think I can use it later like /dev/sda1. /dev/sda1 is not very well, because it isn't continuously (the disk can have sda or sdb and so on). Oct 15, 2021 at 10:35
  • Well you got the right idea but the wrong device type. ENV{DEVTYPE}=="usb_device" is the "low-level" device that deals with raw USB packets, on top of which the OS will layer a usb_interface, then an scsi_host, then probably something like SCSI target and LUN, and only then you get sda as an abstract "block device" which can be mounted or partitioned. (And which, by the way, already has quite a few such symlinks predefined under /dev/disk/by-xxx for exactly the reason that you mention.) Oct 15, 2021 at 10:42
  • @user1686 Yes, your right. I think this is a better way. Thank you very much! Oct 15, 2021 at 11:34

1 Answer 1

1

I'm unable to test this at the moment, but my suspicion is that you should be using ACTION!="remove" – certain things set via udev rules are not sticky across events so instead of only matching "add" you should also match "bind", "change", and so on.

(Do not just replace "add" with "bind", as you have no guarantee that there will always be exactly these two events in exactly that order.)


However, the device you're trying to match will not be very useful if the goal is to mount it like a disk. The 'usb_device' devtype is the "low-level" device that deals with raw USB packets – on top of which the OS will layer a usb_interface, then an scsi_host, then probably something like SCSI target and LUN, and only then you get 'sda' as an abstract "block device" which can be mounted or partitioned.

To actually get something useful, you need to match SUBSYSTEM=="block" (which covers both 'sda' and 'sdaX'), and optionally either devtype "disk" or "partition" to narrow things down.

Also, these block devices actually already have various symlinks predefined under /dev/disk/by-xxx – some of them involving filesystem IDs, partition IDs, and hardware serial numbers as well.

4
  • ACTION=="bind" seems to work! (: Oct 15, 2021 at 11:38
  • I think you entirely missed my point then... the whole reason for this udev behavior is that new action types have been added, so rules that were expecting specifically "add" broke because newer kernels started sending "add" then "bind". Oct 15, 2021 at 12:04
  • Thank you for your explanation! I think I will use the approach with dev/disk/by-xxx Oct 15, 2021 at 12:35
  • This is a very helpful answer in many scenarios and it was difficult to find this tip (ACTION!="remove"), so 6 years later I am a random human saying thanks. The explanation is excellent as well.
    – raindog308
    Jan 17, 2022 at 20:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .