32

I am trying to acquaint myself with udev, under Ubuntu 13.10 (Saucy Salamander).

Here is my first simple 95.usbbackup.rules rule:

ACTION=="add", SUBSYSTEMS="usb", RUN+="/usr/local/bin/my_backup.sh"

And here is the script (which has been chmodded +x) my_backup.sh:

#!/bin/bash
touch /tmp/test

Nothing at all happens when I plug in external drives. How can I check (a log, a command, anything) if the rule fired?

Peter Mortensen
  • 12,090
  • 23
  • 70
  • 90
pouzzler
  • 455
  • 1
  • 4
  • 8
  • 2
    I think you mean `SUBSYSTEMS=="usb"`. I.e. double `==` which tests for equality rather than single `=` which assigns a value to a key. – Lqueryvg Sep 26 '15 at 13:31
  • That rule (once fixed, see previous comment) would run for *every* USB device plugged into USB ports (mouse, camera, even turning on your monitor with integrated USB hub connected to pc!) What you probably want is a rule to trigger on `block` subsystem matching either `ENV{ID_FS_UUID}`, `ATTRS{serial}`, or `ATTRS{idVendor}`/`ATTRS{idProduct}`... If you really want to backup to any USB block device, match `ENV{ID_BUS}=="usb"`. Also keep in mind a rule that is too generic may run multiple times for a single device add, so you may want to match something else like `ENV{DEVTYPE}=="partition"` too. – Thomas Guyot-Sionnest Aug 11 '20 at 10:53

7 Answers7

18

With udev / systemd version 241 and similar, as root:

udevadm control --log-priority=debug
journalctl -f

Or to make it permanent, again as root:

vi /etc/udev/udev.conf
# edit the log level as described in "man udev.conf"
systemctl restart systemd-udevd
journalctl -f

PS: the most frequent yet IMHO wrong answer looks like:

udevadm -d test /devices/where/is/my/device |& less

... but this has a number of issues. The main ones:

  • where/is/my/device ? Tedious, complicated and error-prone.

  • Comparing old answers to recent udev version 241 output, udevadm test seems to show less information that it used to.

  • udevadm -d test is only a simulation! Every time it warns:

    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.

udevadm test is for developing a new rule, it's not for troubleshooting broken, missing or overridden rules.

MarcH
  • 422
  • 4
  • 10
8

udevadm test $(udevadm info --query=path --name=device_name) should tell you which commands would be executed on a device plug in, citing the udev rules involved. For instance:

# udevadm test /block/sdd
...
udev_rules_apply_to_event: PROGRAM '/sbin/multipath -c /dev/sdd' /lib/udev/rules.d/40-multipath.rules:11
...
Dmitry Grigoryev
  • 9,151
  • 4
  • 43
  • 77
7

I'm pretty sure this should work. Reload your udev rules after editing your rules:

udevadm control --reload-rules && udevadm trigger as root.

Peter Mortensen
  • 12,090
  • 23
  • 70
  • 90
Redsandro
  • 564
  • 1
  • 9
  • 18
4

I'm running kernel 3.0.35, but the following works for me.

To get the path for the device you can do something like this:

udevadm info --name /dev/sda1 --query all

You will get more information than you need, but you're interested in the DEVPATH.

Then to see what udev rules are executed, you run this:

udevadm test DEVPATH

I don't think this actually executes the rules. The documentation says this 'simulates' the events for the given device. To get more information, check out the man page for udevadm.

Peter Mortensen
  • 12,090
  • 23
  • 70
  • 90
2

One thing I ended up doing, on a system where I had somewhat limited ability to change stuff (enable debug, change logging, etc - I could do it but I would have to override some configuration management tools) is to simply run an additional command that log to /tmp. You can for example add a 2nd run command:

RUN+="/bin/sh -c 'echo $(date) $(env) >>/tmp/udev-debug.log'"

Add anything you like there, including string substitutions described in udev manpage. Make sure you append the log so you catch every udev invocation matching your rule (it may run multiple times for a single added device, which may or may not be what you want...)

Thomas Guyot-Sionnest
  • 1,271
  • 13
  • 14
2

You can give a command as root like this:

udevadm monitor

It will show when a rule has fired.

  • 14
    `udevadm monitor` just shows the udev events, but not if a corresponding rule was fired. However, you can look for the event which should trigger the rule, but then you do not know if your rule works. – F.Raab Jun 20 '18 at 14:18
0

I was having the same problem with Raspberry Pi 3 B+. I was trying to invoke a script on inserting a USB storage device. The rules do not get logged in syslog, so it becomes very difficult to understand which rule worked or which rule failed.

So I did the following:

  1. I made my rule file in /etc/udev/rules.d/100-myrule.rules
  2. Then I ran the command sudo /etc/init.d/udev restart

and when I checked, it worked.

A piece of information, that may or may not be useful, is that the filesystems are readonly for udev until the command in step 2 is executed.

Blackwood
  • 3,123
  • 11
  • 23
  • 32
MSharq
  • 1
  • 2
    Why did you name the rule as `100-myrule.rules`? The rule is executed before any rules whose name start by "10-" or e.g. by "20-". – jarno Nov 07 '21 at 08:39