34

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,326
pouzzler
  • 475

7 Answers7

24

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
  • 481
11

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,861
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,326
Redsandro
  • 564
  • 1
  • 9
  • 18
6

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,326
JSunderland
  • 61
5

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,471
2

You can give a command as root like this:

udevadm monitor

It will show when a rule has fired.

user2703782
  • 61
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,184
MSharq
  • 1