From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergey Vlasov Date: Sat, 10 Mar 2007 15:05:10 +0000 Subject: wrong names in /dev/.udev/failed for renamed network interfaces Message-Id: <20070310150510.GI15271@master.mivlgu.local> MIME-Version: 1 Content-Type: multipart/mixed; boundary="===============0911660264==" List-Id: To: linux-hotplug@vger.kernel.org --===============0911660264== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gJNQRAHI5jiYqw2y" Content-Disposition: inline --gJNQRAHI5jiYqw2y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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? --=20 Sergey Vlasov --gJNQRAHI5jiYqw2y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFF8skmW82GfkQfsqIRAmcUAJ4qhOzo3AcegVeUdLHHr0HsVbFF8QCfcpeS L21CpjdWksccFdnV1VnNdis= =foEk -----END PGP SIGNATURE----- --gJNQRAHI5jiYqw2y-- --===============0911660264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- 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 --===============0911660264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0911660264==--