Thanks for the great info. I'm mostly sold that the current behavior is a intended. I'm using a read-only-root distribution, and as such I started this process of solving device incrementation by moving /etc/ udev/rules.d to a symlink to a writable partition. However, I did discover a few things along the way which inspired this patch. Firstly, the rules in /dev/.udev are essentially "write only". Udevd does not monitor this directory, which on the surface is okay if you assume you will only need it briefly while in initrd. However, since udevd never reads these rules, a device "flicker" during boot (e.g. a usb network device detaches and re-attaches due to initial firmware load) will cause two rules for the same device to be written to the / dev/.udevd tmp-.rules file. The reason for that us dual. When the device reattaches, udev finds no rules since it doesn't monitor that directory so "NAME=" I'd never assigned by the time the 75-persistent-rules generator runs. The generator script doesn't care that the MAC or other identifiers for this device are identical -- it just makes sure that if an "eth0" already exists, that it now name the device "eth1". So I was confused about who if anyone puts rules in /dev/.udevd/ rules.d. I read the comment in the generator code and it seemed to imply that the location it was writing to would be seen by udev, so I just assumed it was a mistake and merged the two. If that's not correct, could someone clarify why that is worse than what is there now? This way rules created by the generator go directly into udev instead of waiing until later in the boot cycle. Secondly, assuming the current configuration has always been the case, I would assume nobody has actually tested that inotify works on / dev/.udevd/rules.d if the directory does not already exist before udevd has started. I have done this myself and it does not. If that is unexpected behavior for udevd, I'll hunt down the issue in the C code and send a patch for that instead of one for the unit script. Thanks so much for the responses! -- Paul On May 26, 2010, at 11:02 PM, Kay Sievers <kay.sievers@xxxxxxxx> wrote: > On Thu, May 27, 2010 at 01:03, Paul Stewart <pstew@xxxxxxxxxx> wrote: >> Fix udev issue where temporary persistent rules are written in one >> place and read from another. The upstream udev release placed >> dynamic >> persistent rules (ones that get deleted every reboot) in /dev/.udev/, >> but the actual udev daemon read these rules out of >> /dev/.udev/rules.d/. > > I think these temporary rules have never been expected to be read by > the udev daemon directly. > >> The side effect of this is that if the static >> directory (/etc/udev/rules.d) is not writeable (read-only root >> filesystem, for example), device interfaces keep getting renamed >> wlan0, wlan1, wlan2, etc, if they are plugged and unplugged or if >> udevd restarts. > > The temporary rules files, which might be created in /dev/.udev/ are > supposed to be copied to /etc/udev/rules.d/ as soon as the rootfs is > writable. There should be no restart of udevd in the meantime. :) > > What kind of system you are seeing problems? Is it a known > distribution? > > How do you handle the temporary rules files you copy into > /dev/.udev/rules.d/? How do they get into /etc? > >> Note that this change by itself won't work on most distributions >> (with >> read only fses) unless they they also make sure that the >> /dev/.udev/rules.d directory is created before udevd starts up, since >> otherwise the inotify will never trigger for that directory since it >> didn't exist when the inotify call was made. > > What do you mean? Udevd itself creates this directory, and watches it > with inotify. > > Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
