Take the 2-minute tour ×

Trying to run a script when my phone is plugged in via USB, a made a udev rule looks like this in /etc/udev/rules.d/85-lazydroid.rule

ATTRS{idVendor}=="22b8", ATTRS{idProduct}=="428c", RUN+="/home/joel/.lazydroid"

And the script .lazydroid looks like this:

exec adb forward tcp:8080 tcp:8080 &
exec chromium-browser --new-window &

The script itself runs fine. The trick is I can't get the script to run up on insertion of the phone.

And it's the right ID according to: lsusb | grep Motorola

Bus 002 Device 042: ID 22b8:428c Motorola PCS

Any ideas?

[EDIT] Ok, know i know the udev rule is running, creates the symlink, made som changes to the rule, see below:

SUBSYSTEM=="usb", ATTRS{idVendor}=="22b8", ATTRS{idProduct}=="428c", SYMLINK+="phone", RUN+="/bin/sh /home/joel/.lazydroid.sh"

But still the script wont run. And still if I run i separately it runs perfect.

share|improve this question
add comment

3 Answers

up vote 2 down vote accepted

You can test if your rule will be hit or not by running

udevadm test /path/to/sysfs/dev

You can find the devices sysfs node by using this:

udevadm info -q path -n /dev/sda  #To find sysfs node for first HDD

So to wrap that all together it'll be:

udevadm test $(udevadm info -q path -n /dev/sda) 2>&1 | more

Grep that for your script's name or read it line by line if you want. If your script is called but isn't executing then remember you don't have a typical environment in a udev script and so you must call all programs by their full path or otherwise recreate the environment to your liking. Try replacing adb and chromium-browser with their absolute paths (which adb and which chromium-browser)

Also the second exec in your bash script wont execute like you expect as the environment doesn't specify a window system for Chromium to launch in. I think I understand what you were trying to do here, but udev is designed to be non-interactive.

In response to your comment. There are a few abstract screens on every unix system referred to as displays. X11, which is the window manager (think explorer.exe, sort of) for Ubuntu occupies one of them (7 or 8 I think, I work via ssh mostly). When you run a graphical program from the command line (say gedit) it will check the DISPLAY environment variable to determine which display it will draw itself on.

There's more to it that this, and I've never personally gotten a firm understanding of what the 'other stuff' is going on back there, but I'd try to do a few diagnostic things from your script:

mkdir /tmp/udev-script
/usr/bin/printenv > /tmp/udev-script/environment.log
/bin/echo "My script was run!" > /tmp/udev-script/script.log
DISPLAY=:8      # or :7, play around with that
export DISPLAY  # Promote shell variable to environment variable
exec /path/to/chromium 2> /tmp/udev-script/chromium.log 1>&2 &
exit            # This is important for udev, see sources

source2(man udevadm)

share|improve this answer
Thanks, starting to understand this now. But still no luck. Can see that the script is called, and change to the real paths inside the script. But still no go. What did you mean with "Also the second exec in your bash script wont execute like you expect as the environment doesn't specify a window system for Chromium to launch in"? –  choel Apr 14 '12 at 21:54
It was frustrating the last time I did this too. There are environment variables that define lots of things in unix. Most of which I don't get, but some of which I do. One of them controls which 'display' applications should exist in. I believe X11 (the window manager) uses 8 by default, which is why CTRL+ALT+F1 puts you on tty1 and CTRL+ALT+F8 puts you back in your desktop. That is governed in some part by the DISPLAY environment variable, but there's more too it than that. you can try adding DISPLAY=:*; export DISPLAY in your script and see if that helps. –  Huckle Apr 15 '12 at 3:20
(read the edit above first) I'm beginning to remember that the 'other stuff' had to do with who owned the display. The logged in user owns the display that X11 is in, but udev is run as root. Keep that in mind, might help, might not. –  Huckle Apr 15 '12 at 3:35
Ok, the script runs fine, the problem is the opening of chrome on a display. Tries different displays but I think the problem is that the script is run as root and root does not own any displays. So the question now is how do I run a script from udev as user or make sure root can access the user display. Think I'll start a new question about that. Thanks for the help. –  choel Apr 15 '12 at 8:38
add comment

I think you are on the correct path.

You probably want to split this into two scripts -

Use a basic script in udev, which runs another script and exits; the exit is important, because the udev rule will otherwise wait for script one and two to finish before mounting.

Your .lazydroid should be

/home/joel/auto_mount.sh & exit

Give it execute rights:

chmod +x .lazydroid

Then /home/joel/auto_mount.sh should be the contents of your original .lazydroid file

Add a sleep 5 to wait 5 seconds before running the rest of your script.

Again give it execute rights:

chmod +x auto_mount.sh

full credit

share|improve this answer
well, tried that, still no go. It looks like the udev rule isn't launched or the rule it self does not runt the script. As before the script itself runs fine. Is there a way of checking if the rule is being used upon connection? –  choel Apr 14 '12 at 13:54
add comment

I think the problem is in the way you specified RUN You should write RUN+="/bin/bash /home/joel/.lazydroid.sh" Also first try to run a simple script like copy a existing file to another location.

Hope it helps ;)

share|improve this answer
add comment

Your Answer


