Problem with udev rules

Question

I'm having difficulties running a .sh script when I plug in a Bluetooth keyboard.

I'm using the following udev rule:

ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="./scripts/icleverkeybindings.sh"

The script doesn't appear to be activated when I connect my keyboard. I have also tried "./scripts/icleverkeybindings.sh", "/bin/bash /scripts/icleverkeybindings.sh", and "sh /scripts/icleverkeybindings.sh". I don't understand why this script is not activated.

If I instead use the following udev rule

ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/bin/mkdir /home/joe/tempfolder"

Then the folder /home/joe/tempfolder is created when I connect the keyboard.

I have saved the rule in /etc/udev/rules.d/50-addicleverkeybindings.sh. The permissions etc. are: -rw-r--r-- 1 joe root 80 Aug 11 19:53 50-addicleverkeyboard.rules.

The script that I'm trying to run is the following:

#!/bin/bash

sleep 1
cheese

remote_id=$(
    xinput list |
    sed -n 's/.*iClever IC-BK06 Keyboard  .*id=\([0-9]*\).*keyboard.*/\1/p'
)
[ "$remote_id" ] || exit

xkbcomp -i $remote_id /scripts/icleverlayout.xkb $DISPLAY

And ls -la gives -rwxr-xr-x 1 joe root 222 Aug 11 20:00 icleverkeybindings.sh.

If I call simply /scripts/icleverkeybindings.sh from the terminal this works fine.

The script changes the key bindings for my keyboard, I added in the pause in case somehow the script was getting called before xinput knew the keyboard was there, and I added in cheese just to make sure that I knew if it was definitely getting called or not.

Can anyone advise me on how to change my rule so that the script is called?

Thank you

EDIT: To clarify, I created a folder /scripts/, so /scripts/icleverkeybindings.sh is the absolute filepath

what is the full path of ./scripts directory? .... do you have a /scripts directory in your filesystem? — jsotola, Aug 11 '19 at 19:34
/scripts/icleverkeybindings.sh is the full path. does 'make sure the executable bit is set' mean 'run chmod +x ' on the script? because I did that — Jojo, Aug 11 '19 at 20:33
It is better to set that configuration within xorg (i dont know much xkbcomp), udev is an alien to the source and target. Like in https://unix.stackexchange.com/a/439528/12209 — user.dz, Oct 14 '19 at 10:49

Arkadiusz Drabczyk · Answer 1 · 2019-08-11T20:16:32.703

As it says in man udev:

   RUN{type}
       Add a program to the list of programs to be executed after
       processing all the rules for a specific event, depending on
       "type":

       "program"
           Execute an external program specified as the assigned
           value. If no absolute path is given, the program is
           expected to live in /lib/udev; otherwise, the absolute
           path must be specified.

You can also check what udev logs:

Aug 11 21:57:43 ja-VirtualBox systemd-udevd[2998]: failed to execute '/lib/udev/./scripts/icleverkeybindings.sh' './scripts/icleverkeybindings.sh': No such file or directory

Or non-systemd systems:

[769712.027218] udevd[13015]: failed to execute '/lib/udev/./scripts/icleverkeybindings.sh' './scripts/icleverkeybindings.sh': No such file or directory

That being said, you have to either pass an absolute path to icleverkeybindings.sh in your udev rule, something like this:

ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/path/to/icleverkeybindings.sh"

or put icleverkeybindings.sh in /lib/udev and just use a filename in udev rule:

ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="icleverkeybindings.sh"

In both cases you need to make sure that icleverkeybindings.sh has an executable bit is set because otherwise:

Aug 11 22:07:49 ja-VirtualBox systemd-udevd[3345]: failed to execute '/lib/udev/icleverkeybindings.sh' 'icleverkeybindings.sh': Permission denied
Aug 11 22:07:49 ja-VirtualBox systemd-udevd[3325]: Process 'icleverkeybindings.sh' failed with exit code 2.

Thanks for your answer. I did set the executable bit for the script, and I did put the absolute path. How did you check the udev log? — Jojo, Aug 11 '19 at 20:37
It depends on your system configuration, it might be in /var/log/syslog or in dmesg. — Arkadiusz Drabczyk, Aug 11 '19 at 20:42

Problem with udev rules

1 Answers1