I made a script in /etc/udev/rules.d/local.rules
SUBSYSTEM=="usb", SYSFS{idVendor=="b58e"}, SYSFS{idProduct=="9e84"}, ACTION=="add", RUN+="notify-send USB"
I then reload udev with
sudo udevadm control --reload-rules
I've tried to remove everything but subsystem and run. I've tried the run '=' instead of '+=', I've tired ATTR instead of SYSFS. I tried "sudo service udev restart" and "sudo reload udev". I unplug the device, then plug it in again and it does not run the action. I tried renaming it 70-local.rules and changing permissions to a+x. I've tried changing 'subsystem' to 'bus'. I've tried setting run to be "/path/test.sh" which has the same command.
I'm not an expert and this isn't an answer, but I've found the following steps useful in identifying the appropriate attributes to trigger on:
udevadm
, lsusb
, or usb-devices
. I normally just use lsusb
and let tab completion in my shell guide me. In my case, the path is /dev/bus/usb/003/007
.udevadm
to identify the device attributes for rule writing. In my case, I used udevadm info -a --attribute-walk --root --name=/dev/bus/usb/003/007
.ls -l /dev/bus/usb/003/007
. My rule for this case looks like: SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", OWNER="stephen"
. I have a similar rule that puzzled me for a little while because the subsystem was expecting ATTRS
not ATTR
, which is why I recommend walking the attributes. The rule in this latter case became: `SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", OWNER="stephen".And, of course, man udev
is always helpful. As you said, you should struggle to identify that your rule is triggering properly and may be best off just doing a quick ownership change on the device as I did for a first step. You can run into trouble with bad attributes or symbolic links sometimes and it's
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With