Re: UDEV: A question about %c, RUN+=

[Pavel Troller <patrol@sinus.cz>]

>On Dec 10, 2007 11:03 AM, Pavel Troller <patrol@si...> wrote:
> > I would like to ask, whether the following is an intentional behaviour or
> > a bug:
> >
> > Let's have two rules:
> > KERNEL="sd?", ACTION="remove", PROGRAM="find_dev_from_part.sh %r %k flash", RESULT="flash*", RUN+="/bin/rm %r/%c"
> > KERNEL="sd?", ACTION="remove", PROGRAM="find_dev_from_part.sh %r %k card", RESULT="card*", RUN+="/bin/rm %r/%c"
> >
> > These rules try to find a symlink of a sd* node, which can be either flash*
> > or card*, and remove it when the node is removed.
> > The find_dev_from_part.sh script finds possible link using a "base" name and
> > returns its name in stdout. If the link is not found, stdout is empty.
> > The following RESULT= test checks, whether the result is OK.
> > When exactly this ruleset is applied, and, say, sdc is removed, which has
> > a link as flash0, the FIRST rule RUN command is applied, but it tries to
> > rm /dev/ . I've found, that the %c value for the RUN command is taken
> > from the SECOND rule, where it was empty, because the link is named flash0,
> > not card0. So, a RUN command is run from the first rule, taking %c from
> > the second one, which doesn't work.
> > I solved this problem by enterning an ENV{} variable different for each rule
> > and assigning %c to it immediately after the PROGRAM evaluates and using it
> > in the RUN command It helps. But I feel this behaviour as buggy.
> > All this was tested with udev-117.
> > Any explanation would be greatly appreciated.
> > Please cc: to me, as I'm not a regular member of the list.
> 
> It's expected behavior, RUN keys are queued until all rule processing
> has finished. The %c value represents the result of the _last_ PROGRAM
> that was executed during rule processing.
OK, thanks for a quick explanation. I thought so, but for sure I asked :-).
> 
> What are you trying to do here? Remove a symlink with "rm"? Why
> don't you let udev create the symlink, and it will remove it when the device
> goes away?

Because the example is a little simplified. The rm command removes not only
the symlink, but also a mountpoint in /media and I'm planning to enhance
its functionality even more, to edit /etc/fstab and do other things...

> You can have multiple devices claim the same symlink name, you can
> specify priorities for the device, and the one with the highest number will
> always win. Without priorities specified, a new device will overwrite the
> older symlink, and if it goes away again, the old symlink will be restored.
> 
It seems that available documentation is rather incomplete. For example, the
"priority" word in man udev(7) is mentioned only related to syslogging :-).
In the "writing udev rules" document, there is nothing about it. There are
documents "for the sentimental reasons" in the source package, but not the
current ones. Is somewhere a and up-to-date udev doc ?

With regards, Pavel Troller


-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel