udev rule not triggered

English Hardware
1

Hello !

To automatically start my backup when I attach my USB “Backup” disk, I created the following udevd rule:


ACTION=="add", SUBSYSTEM=="block", ENV{ID_TYPE}=="disk", ENV{ID_FS_LABEL}=="Backup", RUN+="/root/bin/backup.pl"

For some reason, this rule is however not triggered. When I run “udevadm monitor --env”, I see among others the following result:


UDEV  [1334.167464] add      /devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5:1.0/host14/target14:0:0/14:0:0:0/block/sdh/sdh1 (block)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5:1.0/host14/target14:0:0/14:0:0:0/block/sdh/sdh1
SUBSYSTEM=block
DEVNAME=/dev/sdh1
DEVTYPE=partition
SEQNUM=2433
ID_VENDOR=Generic
ID_VENDOR_ENC=Generic\x20
ID_VENDOR_ID=058f
ID_MODEL=USB_Disk
ID_MODEL_ENC=USB\x20Disk\x20\x20\x20\x20\x20\x20\x20\x20
ID_MODEL_ID=6390
ID_REVISION=9.02
ID_SERIAL=Generic_USB_Disk-0:0
ID_TYPE=disk
ID_INSTANCE=0:0
ID_BUS=usb
ID_USB_INTERFACES=:080650:
ID_USB_INTERFACE_NUM=00
ID_USB_DRIVER=usb-storage
ID_PATH=pci-0000:00:1a.7-usb-0:5:1.0-scsi-0:0:0:0
ID_PATH_TAG=pci-0000_00_1a_7-usb-0_5_1_0-scsi-0_0_0_0
ID_PART_TABLE_TYPE=dos
ID_FS_LABEL=Backup
ID_FS_LABEL_ENC=Backup
ID_FS_UUID=6446279f-0a13-4847-9324-10c051bdb451
ID_FS_UUID_ENC=6446279f-0a13-4847-9324-10c051bdb451
ID_FS_VERSION=1.0
ID_FS_TYPE=ext4
ID_FS_USAGE=filesystem
ID_PART_ENTRY_SCHEME=dos
ID_PART_ENTRY_TYPE=0x83
ID_PART_ENTRY_NUMBER=1
ID_PART_ENTRY_OFFSET=16065
ID_PART_ENTRY_SIZE=156280320
ID_PART_ENTRY_DISK=8:112
UDISKS_PRESENTATION_NOPOLICY=0
UDISKS_PARTITION=1
UDISKS_PARTITION_SCHEME=mbr
UDISKS_PARTITION_NUMBER=1
UDISKS_PARTITION_TYPE=0x83
UDISKS_PARTITION_SIZE=80015523840
UDISKS_PARTITION_SLAVE=/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5:1.0/host14/target14:0:0/14:0:0:0/block/sdh
UDISKS_PARTITION_OFFSET=8225280
UDISKS_PARTITION_ALIGNMENT_OFFSET=0
MAJOR=8
MINOR=113
DEVLINKS=/dev/disk/by-id/usb-Generic_USB_Disk-0:0-part1 /dev/disk/by-path/pci-0000:00:1a.7-usb-0:5:1.0-scsi-0:0:0:0-part1 /dev/disk/b
TAGS=:systemd:

As far as I can see, ACTION (“add”), SUBSYSTEM (“block”), ENV{ID_TYPE} (“disk”) and ENV{ID_FS_LABEL} (“Backup”) all match. The script called by this action runs flawlessly when started from console. This used to run with SuSE 11.x, but I am not sure if I changed something different apart from the upgrade when I switched to SuSE 12.1.

What is going wrong here?

Regards, Wumpus / Sven H.

2

I am by no way an expert here, but what I miss in your listing almost at the end in the DEVLINKS line is the creation of a* /dev/disk/by-label/* entry. Is that because the line is broken off? It looks a bit like that. Or is it because your label is not there?

Just my 2 cents.

3

I don’t see anything wrong (syntax-wise) with your udev rule, but I do have a question: Does your script also do the mounting of this usb storage device? (Remember usb devices are not necessarily automatically mounted, although the desktop environment may be configured to do so).

4

That line is indeed broken off. The entry is there !

5

Currently, the desktop is configured accordingly (I might change that in future). I also replaced the application with a simple script which just creates a syslog entry to see if the application is started at all. Is there any way to let udevd report which rules matched and what actions are intended to be executed ?

6

Just an idea: You might try using alternative SUBSYSTEMS and ATTRS match keys. For example, plug in your device

fdisk -l

Note the usb device reported (eg /dev/sdb1), then execute something similar to

udevadm info -a -p $(udevadm info -q path -n /dev/sdb1)

An example rule

ACTION=="add", SUBSYSTEMS=="usb", ATTRS{serial}=="0000:00:1d.7", RUN+="/root/bin/backup.pl"
  • I do know that when choosing device properties, it is not possible to match values from more than one parent device in the chain.
7

You might find this documentations useful:

Chapter

and a good example for others searching for help on this

How to write udev rules - Hack a Day

8

Is there any way to let udevd report which rules matched and what actions are intended to be executed ?

This might be a helpful approach for debugging

Custom udev rules and external program debugging - rootninja

Essentially, the method involves running udevd in the foreground and in debug mode (to increase the verbosity).

9

Good hint, albeit with systemd just a “kill” was no enough - udevd got respawned immediately. Instead, I had to do


systemctl stop udev.service
systemctl stop udev-control.socket
systemctl stop udev-kernel.socket
udevd --debug

Finally, debugging worked - and I got the problem. I put the rule to “49-wumpus.rules” which was simply too early - I moved it to “99-wumpus.rules” and voila ! Threre we go.
Thanx a lot for help !

10

Good hint, albeit with systemd just a “kill” was no enough - udevd got respawned immediately. Instead, I had to do…

Thanks for the info concerning the behaviour of systemd. I’m not yet up to speed with it, as I’m still with openSUSE 11.4. I’m sure this will be helpful to others who come searching.

Finally, debugging worked - and I got the problem. I put the rule to “49-wumpus.rules” which was simply too early - I moved it to “99-wumpus.rules” and voila ! Threre we go.
Thanx a lot for help !

Ah, yes, another rule was being being matched and processed later in the chain. Great result and glad to have been of help.

11

Thanks you both for this discussion. It is a great example of what can be done with udev rules and as such it could be an inspiration for others.

Also the more examples of the usage of systemd we see here on the forums, the better. We all have to learn a lot there.