udev rule not working

24,215

Solution 1

This is my working udev rule for executing backup on hotplug:

SUBSYSTEM=="block" ACTION=="add" \
      ENV{DEVTYPE}=="partition" \
      ENV{ID_FS_UUID}=="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
      TAG+="store" \
      RUN+="/usr/bin/python3 /etc/systemd/autoback.py --udev"

Note that instead of matching the USB device, I'm matching a partition (i.e. /dev/sde1) on the mass storage endpoint of that usb device. It takes a few seconds after the USB hotplug before the disk is ready and the partition is enumerated so this is the "right" event for my use case, and probably yours too if you're trying to do backups. ID_FS_UUID is the same as reported by blkid for this partition. In my case, this is the luks UUID.

On my system udev doesn't seem to automatically reload correctly when I edit rules, but what I've found to work (which is also useful for debugging) is:

udevadm test /sys/dev/block/8:65

to force a reload/re-application of udev rules. Note that I found 8:65 by ls -l /dev/block | grep sde1. Also

udevadm info --query=property /dev/sde1

was helpful to see if my rules are applied, and

NOTE: I'm posting this answer 5 years after the OP, so things might be different now than then. My system is ubuntu 16.04.4 (xenial) on arm64.

Solution 2

You have misspelled ATTR, it should be ATTRS in this case.

Solution 3

Try having a look at the output for udevadm info --path=path/to/device --attribute-walk It will tell you every attribute and subsystem that's valid for the device. For instance, a USB device I have has a SUBSYSTEM="tty", to recognize USB for that device you need to put SUBSYSTEMS=="usb" (note: plural subsystem*s*). I suspect that something like that may be the case here. Either way udevadm info --attribute-walk is a really helpful tool for debugging udev problems.

Also ATTR{key} is not valid, instead use ATTRS{key} (It was mentioned before, but some of your examples still use the incorrect form.)

Share:
24,215

Related videos on Youtube

Edelweiss
Author by

Edelweiss

Updated on September 18, 2022

Comments

  • Edelweiss
    Edelweiss over 1 year

    I have created a udev rules which is supposed to mount a USB device, backup some datas et cleanup everything. I am actually working on a Debian server.

    There is the information about my usb device that I have with lsusb

    Bus 001 Device 003: ID 054c:0243 Sony Corp. MicroVault Flash Drive

    (Actually the lsusb returns more Bus / Device, but I have to write them by hand since I am not posting from my Debian machine :))

    Then I have written my udev rule called :

    10-usb_back.rules
    

    into:

    /etc/udev/rules.d/
    

    (I used 95 because the backup script takes some seconds and I want to run it as late as I can for avoiding to delay other stuff)

    And finally the rule itself:

    ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTR{idProduct}=="0243", RUN+="/usr/local/bin/mount_usb"
    ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTR{idProduct}=="0243", RUN+="/usr/local/bin/backup_database"
    

    I have tried this too:

    ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="054c", ATTR{idProduct}=="0234", RUN+="bash /usr/local/bin/mount_usb"
    

    Unsuccessfully :(

    Then I restart udev

    sudo /etc/init.d/udev restart
    

    And when I plug my USB device I got this weird message:

    [1348.295280] sd 6:0:0:0: [sdc] Assuming drive cache: write through

    twice

    But nothing happened. No USB device mounted, no data backed up.

    I looked with tail -f /var/log/message
    

    And the USB drive looks like detected:

    usb 1-3: Product Storage Media 
    usb 1-3 Manufacturer Sony`
    ...
    

    Something must be wrong somewhere but I don't know what, neither where :(

    Edit: Since I've been a little bit lazy because I can't rewrite everything from my server, please ask for further information if needed, such as the script or more logs messages :)

    • Kotte
      Kotte about 11 years
      You can use the command at raftaman.net/?p=343 to check for more information on the usb drive. Also, the C program on the bottom of kernel.org/doc/pending/hotplug.txt is really useful for listening to uevents, which makes it easier to see what information you can use. Could also be as simple as some earlier rule is declared as final rule.
    • Edelweiss
      Edelweiss about 11 years
      I will take a look at the C program, but it's looks like a little bit tricky, isn't it?
    • Kotte
      Kotte about 11 years
      Somewhat, but you don't need to understand it. It is useful as a util :). Btw, I think you misspelled ATTR, should be ATTRS for usb properties.
    • Admin
      Admin about 11 years
      I had the same problem a while ago. Mabye that solution will work for you too.
    • Edelweiss
      Edelweiss almost 11 years
      So, I've been busy last week with an emergency. So I ran the command udevadm test --action=add /devices/pci0000:00/0000:00:1d.7/usb1/1-3and the ouput is a list with some informations about my device, such as ID_VENDOR, ID_MODEL,...
    • jippie
      jippie over 10 years
      you can check what is happening with unbuffer udevadm monitor --environment. unbuffer is in expect-dev and ensures that your output is continuously updated (rather than buffered in 4kB blocks causing you sometimes to mis the last messages).
  • Edelweiss
    Edelweiss about 11 years
    You got a point, i fixed it but still not working, anyway thanks for pointing that out :)
  • Edelweiss
    Edelweiss about 11 years
    Don't know why, but it still no working, I losing any hope for making this stuff working :( Thank you for your contribution
  • Kotte
    Kotte about 11 years
    Also did you restart udev after making changes? udev should react to changes in the settings, but that require inotify to be enabled in the kernel. That might not be the case in embedded systems and the like.
  • Kotte
    Kotte about 11 years
    If you restarted the computer, then udev was already restarted.
  • Edelweiss
    Edelweiss about 11 years
    I changed the name to 10-usb_backup.rules, still not working
  • Alexis Wilke
    Alexis Wilke about 3 years
    Shouldn't it be plural too? (ATTRS)
  • slm
    slm about 3 years
    @AlexisWilke - look at other A'ers didn't seem to make a diff.