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

[Sergey Vlasov <vsu@altlinux.ru>]

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