From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kay Sievers" Date: Wed, 14 Mar 2007 20:56:58 +0000 Subject: Re: wrong names in /dev/.udev/failed for renamed network interfaces Message-Id: <3ae72650703141356x5f884d53pccf1439f10ef4c35@mail.gmail.com> List-Id: References: <20070310150510.GI15271@master.mivlgu.local> In-Reply-To: <20070310150510.GI15271@master.mivlgu.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org On 3/10/07, Sergey Vlasov 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=3Djoin.php&p=3Dsourceforge&CID=DEVD= EV _______________________________________________ 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