2

After getting my 3g-modem to work in Arch Linux I wanted to eliminate some manual labour required in the process. Hence I needed to create an udev rule. After some trial and error I came up with the following rule named 11-my-rule.rules which I placed at /etc/udev/rules.d/:

# start at sdb to ignore the system hard drive
KERNEL!="sd[b-z]*", GOTO="my_media_automount_end"

# run the script and create a testdir to verify the rule works
ACTION=="add", RUN+="/myscript.sh", RUN+="/bin/mkdir -p '/media/pendrive'"

#remove the testfolder on removal of usb
ACTION=="remove", RUN+="/bin/rm -R '/media/pendrive'"

# exit
LABEL="my_media_automount_end"

My testscript which is meant to be ran is as follows:

#!/bin/bash

DISPLAY=:0 xterm

Which displays xterminal. I have tested the script itself and it works. Also the second RUN+ that creates the test-directory works as well. Hence I am at a loss just what am I doing wrong.

Gilles 'SO- stop being evil'
  • 829,060
Tomkarho
  • 123
  • Does root (I assume that's the user which executes the script on the udev trigger) have authority to send xterm to your xwindows session (which is probably not running as root)? – EightBitTony Jun 27 '13 at 12:27

1 Answers1

3

@EightBitTony may be right. The udev rules are executed as the root user. So in addition to specifying the DISPLAY, you need to grant this root user access to your X session.

This can be achived by finding the corresponding authority file and exporting it as XAUTHORITY. echo $XAUTHORITY from a terminal emulator can tell you, where it is.

Using a display manager, the location is likely to change on each login. Alternatively, you can invoke xhost + from your x session, granting all other users access to this session. xhost - would close this again. Be reminded, that this also enables remote users to access the session using a TCP port.

XZS
  • 1,448