UDEV: A question about %c, RUN+=

UDEV: A question about %c, RUN+=

[Pavel Troller]

Hi!
 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.

   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

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

[Kay Sievers]

On Dec 10, 2007 11:03 AM, Pavel Troller <patrol@sinus.cz> 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.

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?
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.

Kay

-------------------------------------------------------------------------
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

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

[Pavel Troller]

>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

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

[Kay Sievers]

On Dec 10, 2007 4:08 PM, Pavel Troller <patrol@sinus.cz> wrote:
>
> >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 ?

In the current udev man page is:
           "link_priority=value
               Specify the priority of the created symlinks. Devices with
               higher priorities overwrite existing symlinks of other devices."

Kay

-------------------------------------------------------------------------
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

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

[Pavel Troller]

> 
> In the current udev man page is:
>            "link_priority=value
>                Specify the priority of the created symlinks. Devices with
>                higher priorities overwrite existing symlinks of other devices."
> 
> Kay
Hi!
  Yes, it it. Sorry for that. My grep was blind :-).
    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