-   Linux - General (
-   -   udev RUN+= doesn't seem to work (

PlancksCnst 05-11-2007 08:50 AM

udev RUN+= doesn't seem to work
I am making a system to copy all my podcasts over to my memory card (my mp3 player uses a memory card) when it is plugged in. I made a script to do the copying and it works just fine - I can call the script and it does the expected behavior. I made a udev rule to automatically run this script when the card is inserted. I also had the rule make a syslink so that the script could reference the same syslink no matter what device (/dev/sdb1, /sda1, etc) the card ended up on. It matches on the model attribute of the device.

The problem: the rule is making the symlink just fine, but it does not seem to be running the script. I have set the script to chmod 777 for testing purposes - so it is definitely executable by whatever user the udev system is using. The path is correct; I can copy straight from the text file and paste it on the command line, and it works. What could be wrong?

The following is the rule:

ATTRS{model}=="Flash*" ACTION=="add", SYMLINK+="memcard", RUN+="/home/shawn/"
I'm certain that the script is fine since I can run it, and it works just fine, but here it is anyway:

echo "preparing to copy podcast directory"
echo "creating mount directory"
mkdir /mnt/memcard
echo "mounting memcard"
mount /dev/memcard /mnt/memcard
echo "removing previous copy"
rm -r /mnt/memcard/media/
echo "making directory for copying into"
mkdir /mnt/memcard/media
echo "copying podcasts..."
cp -r /home/shawn/podcasts/cache /mnt/memcard/media/
echo "done copying... cleaning up"
echo "unmounting memcard"
umount /mnt/memcard
echo "removing mount directory"
rmdir /mnt/memcard
echo "finished"

Thanks for your help!

titopoquito 05-11-2007 05:43 PM

What fell into my mind when reading your question was if it is enough to chmod the script to 777 as long as it might be in a folder that not everyone has access to. So depending on who "owns" the udev process the /home.... folder might be not accessible. Maybe try to put it in /usr/bin for example and see if that helps.

jschiwal 05-11-2007 06:19 PM

For one thing, get rid of the echo statements. Since udev doesn't have access to your console that could be blocking the program.

PlancksCnst 05-11-2007 07:09 PM

I tried both suggestions. I also ran chmod after I copied since I'm not sure if cp preserves permissions (is there a way to see permissions on a file?). I also did udevcontrol reload_rules (although I don't think I need to). It still doesn't work.

jschiwal 05-11-2007 11:03 PM

You can look at the permissions on a file with the "ls -l <filename>" command.

The PATH that exists when the command runs depends on the environment of the UDEV daemon. Look for other run+= entries and locate where the called script is. On my SuSE system, there is a script in /lib/udev/. Also make sure that your rule isn't misplaced preventing the device from being mounted. If you get it working, you may want to add another test, such as ID_FS_LABEL={podcast*}. That way you won't accidently delete everything in a flash drive because of the rule.

You could redirect any errors output to a logfile.
ATTRS{model}=="Flash*" ACTION=="add", SYMLINK+="memcard", RUN+="/lib/udev/ 2&>>/tmp/copypodcast.log"

Matir 05-12-2007 12:58 AM

I suspect that shell scripts may not be executed by udev in this manner. (Just a guess, though) Try running "bash SCRIPTNAME" as the RUN+= command. Also, take note of this excerpt from the manpage:

Add a program to the list of programs to be executed for a specific
device. This can only be used for very short running tasks. Running
an event process for a long period of time may block all further
events for this or a dependent device. Long running tasks need to
be immediately detached from the event process itself.

jschiwal 05-12-2007 01:17 AM


grep /etc/udev/rules.d/*
/etc/udev/rules.d/85-mount-fstab.rules:SUBSYSTEM=="block", ACTION=="add", KERNEL=="sd*[0-9]|hd*[0-9]", RUN+=""
jschiwal@hpamd64:/etc/udev/rules.d> locate
jschiwal@hpamd64:/etc/udev/rules.d> cat /lib/udev/
#! /bin/bash

I would use a script in ~/bin/ after the device was mounted to do something like what the OP wants to do. However if he can get it to work, great. Part of the problem may be that udev rules aren't the best place for it because udev is used to create devices. Also, running a script like that as root just doesn't feel right.

I should have reread the manpage. Copying media files would take a long time. Maybe he could send a signal to a daemon which would copy the files.

I admit I still have a lot to learn about udev and the hal system, plus how the kde daemon interfaces with hal to do the mounting.

Matir 05-12-2007 01:28 AM

Oops, I should've remembered the bit myself. Quite silly, guess it's getting too late.

PlancksCnst 05-12-2007 08:59 AM

Yeah - it's copying 800Mb over a usb 1.0 - it's going to take a while. I think I can detach a process by using:

( &) &
So I moved the script to /lib/udev/ (where all the other udev scripts lie) and changed my rule to:

ATTRS{model}=="Flash*" ACTION=="add", SYMLINK+="memcard", RUN+="(/lib/udev/ &) &"
It still doesn't run the script.

PlancksCnst 05-12-2007 09:03 AM

Does anyone know another way to do what I'm trying to do (copy -or sync- files over to a thumb drive automatically when it is inserted)

jschiwal 05-12-2007 10:22 AM

Here is a Linux Journal article on using udev to backup a thumb drive:

It also uses RUN+= in a udev rule. You might want to read his script. After initializing some variables used in the script, this is the first command it runs:
# wait for device to settle
sleep 10

PlancksCnst 05-13-2007 03:13 PM

Yep - I tried the wait. No luck. I also put a logger message in at the beginning of the script to see if it was even getting that far; it's not.

titopoquito 05-13-2007 03:42 PM

I just tried that myself and what worked was to put in even the full path to bash, for example

BUS=="scsi", KERNEL=="sd*", SYSFS{model}=="HD400LD        ", SYSFS{vendor}=="SAMSUNG ", NAME="%k", SYMLINK="usbhd-trekstor%n", RUN+="/bin/sh /etc/udev/scripts/"
EDIT: That was for just switching on the harddisk and creating the symlink in /dev without mounting it at all. I didn't try the ACTION commands at this point.

Matir 05-13-2007 09:34 PM

Have you tried udevtest with the device path to see what rules are specifically being applied?

Matir 05-13-2007 09:37 PM

Another thought: you may want to try removing the whitespace from the model and vendor strings. Per the udev manpage:

Trailing whitespace in the
attribute values is ignored, if the specified match value does not
contain trailing whitespace itself.

All times are GMT -5. The time now is 12:40 AM.