wrong names in /dev/.udev/failed for renamed network interfaces

wrong names in /dev/.udev/failed for renamed network interfaces

[Sergey Vlasov]

[-- Attachment #1.1: Type: text/plain, Size: 2229 bytes --]

Hello!

I have found a problem with /dev/.udev/failed handling for network
interfaces which are renamed.  Currently I'm using udev-105, but the
version 106 does not seem to have any relevant changes.

Suppose that udevd is handling an "add" event for a network interface,
and there are rules which set NAME and RUN for that interface.  In
this case udevd renames the interface, changing its devpath.  But if
some of subsequently executed RUN commands fail, the queue entry for
the event must be moved to /dev/.udev/failed, so that the event may be
processed again later; the master udevd process does this, but it uses
the initial value of devpath, which is no longer correct.  When at
some later time "udevtrigger --retry-failed" is invoked, the old
devpath does not exist (or, even worse, exists but points at some
other device), therefore the event is not reprocessed properly.

I see several possible solutions to this problem:

 1) Just do nothing; document that udevtrigger --retry-failed is not
    reliable if used together with interface renaming.  This would
    mean that I need to find another solution for reliable
    initialization of hotpluggable network interfaces (e.g., creating
    an own "failed" queue from a RUN script and processing it in some
    special way instead of using udevtrigger).  This also does not
    address the case when the old devpath points to some other
    interface - udevtrigger --retry-failed does not support any
    filtering options, therefore it cannot be used reliably for other
    events without the possibility of disrupting network interfaces
    configured earlier.

 2) Implement some form of communication between the master udevd
    process and forked processes which handle events, so that a forked
    process may report new devpath to the master process.  This should
    fix the problem, but introduces additional complexity.

 3) Move /dev/.udev/failed handling to the event handling process -
    this will break if that process dies for any reason (e.g., due to
    SIGALRM), so not a good solution.

Maybe someone has found this problem before and already has a solution
or a workaround for it?

-- 
Sergey Vlasov

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
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: wrong names in /dev/.udev/failed for renamed network interfaces

[Kay Sievers]

On 3/10/07, Sergey Vlasov <vsu@altlinux.ru> wrote:
> I have found a problem with /dev/.udev/failed handling for network
> interfaces which are renamed.  Currently I'm using udev-105, but the
> version 106 does not seem to have any relevant changes.
>
> Suppose that udevd is handling an "add" event for a network interface,
> and there are rules which set NAME and RUN for that interface.  In
> this case udevd renames the interface, changing its devpath.  But if
> some of subsequently executed RUN commands fail, the queue entry for
> the event must be moved to /dev/.udev/failed, so that the event may be
> processed again later; the master udevd process does this, but it uses
> the initial value of devpath, which is no longer correct.  When at
> some later time "udevtrigger --retry-failed" is invoked, the old
> devpath does not exist (or, even worse, exists but points at some
> other device), therefore the event is not reprocessed properly.
>
> I see several possible solutions to this problem:
>
>  1) Just do nothing; document that udevtrigger --retry-failed is not
>     reliable if used together with interface renaming.  This would
>     mean that I need to find another solution for reliable
>     initialization of hotpluggable network interfaces (e.g., creating
>     an own "failed" queue from a RUN script and processing it in some
>     special way instead of using udevtrigger).  This also does not
>     address the case when the old devpath points to some other
>     interface - udevtrigger --retry-failed does not support any
>     filtering options, therefore it cannot be used reliably for other
>     events without the possibility of disrupting network interfaces
>     configured earlier.
>
>  2) Implement some form of communication between the master udevd
>     process and forked processes which handle events, so that a forked
>     process may report new devpath to the master process.  This should
>     fix the problem, but introduces additional complexity.
>
>  3) Move /dev/.udev/failed handling to the event handling process -
>     this will break if that process dies for any reason (e.g., due to
>     SIGALRM), so not a good solution.

Yeah, that's an currently unresolved problem. We may be able to use
the "move" events, we will add to the kernel, if a device changes its
name. These events will contain DEVPATH and DEVPATH_OLD in the
environment. If that stuff hits the kernel, we can try, if it's
possible to use these events in the daemon, to reflect the actual
state.

Kay

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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