15

I'm creating a new basic rule

/etc/udev/rules.d/10-myrule.rules

containing:

KERNEL!="sdb*", GOTO="auto_mount_end"
ACTION=="add", RUN+="/usr/bin/mount /dev/sdb1 /media"
LABEL="auto_mount_end"

I saved, rebooted, and inserted a SD card (recognized by /dev/sdb1, I see it with dmesg), but nothing happens. When I do manually mount /dev/sdb1 /media, it works.

How can I troubleshoot / debug such an udev rule?

Note: I'm using ArchLinux, but it should be the same on any distro?

  • 1
    Change the filename to 99-myrule.rules... – jasonwryan May 4 '15 at 0:30
  • @jasonwryan : the same : nothing happens. How to troubleshoot an udev rule? Should I trigger it manually (how in this case?) – Basj May 4 '15 at 0:37
  • Does systemd change something to the normal udev behaviour? – Basj May 4 '15 at 0:38
  • 1
    try udevadm monitor, see this and this – Aquarius Power May 8 '15 at 20:42
  • 1
    AFAIK one doesn't neet to reboot in order to get udev to re-read the rules (see unix.stackexchange.com/a/39371/44760). I've done my udev debugging (which indeed isn't the easiest task!) with udevadm test and validated rules against reality with udevadm info. – zagrimsan Jun 2 '15 at 12:45
11
  • 10- as mentioned by jasonwryan, use high numbering (90's good). So you rule is not going to be overridden by another one.
  • Use the minimum keys just as you really need. Example, != & GOTO/LABEL, instead use directly ==

    ACTION=="add", KERNEL=="sdb*", RUN+="/usr/bin/mount /dev/sdb1 /media"
    
  • Your target was sdb1 with fixed command, minimize the blind match using KERNEL=="sdb1"

  • I find it useful to create a shadow debugging rule, I called shadow because I always leave it there in same file, so i use it when i need it.

    ACTION=="add", KERNEL=="sdb*", RUN+="/bin/sh -c 'echo == >> /home/user/Desktop/udev-env.txt; env >> /home/user/Desktop/udev-env.txt'"
    #ACTION=="add", KERNEL=="sdb*", RUN+="/usr/bin/mount /dev/sdb1 /media"
    

    Note: udev-env.txt is created then the rule is triggered anyway. Line == corresponding to one matching node. The ENV recorded in that file could be mixture between 2 node or more, created almost in same time, it's a stdout buffering problem.

  • Use udevadm monitor -u, udevadm test ... and udevadm trigger ... to verify which rules processed the events.

  • Inside the scripts is up to you to make debug log and catch failed commands, by saving their return value also stdout & stderr messages.

Update:

  • Reference: udev_237 - man udev (Ubuntu_18.04)

    RUN{type}

    Note that running programs that access the network or mount/unmount filesystems is not
    allowed inside of udev rules, due to the default sandbox that is enforced on
    systemd-udevd.service.
    
  • 1
    Very useful. A couple of comments udevadm test... appears to only show you environment variables, to gets ATTRS you can use udevadm info $DEVICE to find these other settings. – Att Righ Feb 2 '17 at 18:57
  • 1
    In udevadm info returns a tree of devices be careful to distinguish settings between a device and its parent devices (properties seem to be inherited if not overridden). In my case the subsystem was wrong. – Att Righ Feb 2 '17 at 19:03
  • udevadm test "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." Is there no way to just trace what is actually happening? – MarcH Oct 31 '18 at 0:06
  • @MarcH , you could use udevadm monitor -u to check for events/conditions & udevadm trigger ... to test their actions. – user.dz Oct 31 '18 at 8:42
  • @MarcH , but inside the scripts is up to you to make debug log and catch failed commands (by saving their return value also stdout & stderr messages). – user.dz Oct 31 '18 at 8:50
1

I think the command you're looking for here is udevadm. You'll use the trigger and test parameters to trigger a rescan of the udev events, and to test a specific event, respectively.

I learned this the hard way when putzing around with the new network device naming in EL 7. Good luck!

1
  1. Create a udev rules file

    sudo nano /etc/udev/rules.d/99-removable-sd.rules
    
  2. Add rule that tells udisks to automount it

    SUBSYSTEM=="block", SUBSYSTEMS=="mmc", DRIVERS=="mmcblk", ATTRS{type}=="SD", ENV{UDISKS_AUTO}="1", ENV{UDISKS_SYSTEM}="0"
    

    ATTRS{type}=="SD" may be not required if you are using different types.

  3. Reload rules

    sudo udevadm control -R
    
  4. Eject it then put back.

Reference: Archlinux Wiki: Some devices, that should be treated as removable, are not

0

I was having the same problem with RASPBERRY PI 3 B+, it could be possible that above commands may help you. But it DID NOT help me. 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

then I checked it worked. A piece of information, may be useful to you or may not be, but the filesystems are readonly for udev until the command at (2) is executed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.