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

["Kay Sievers" <kay.sievers@vrfy.org>]

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