On Mon, May 16, 2011 at 12:01, Nix <nix@xxxxxxxxxxxxx> wrote: > On 16 May 2011, Kay Sievers outgrape: >> With devtmpfs you get the "early" /dev for free, and you preserve the >> "early" /dev in the real root. Instead of mounting a 'tmpfs' just >> mount a 'devtmpfs' at /dev, and it will be magically filled already, >> that's the only difference. >> >> When mounting the real root, just mount --move it over to the real >> root before switching to the real root. > > I'll have to see what busybox's switch_root does. I know it deletes > the entire contents of the root directory it switches away from: I'll > have to make sure that doesn't somehow include moved-away mountpoints. > (I doubt it does.) > >> Maybe you can run: >> Â udevadm monitor >> in the background writing to a file, and get timestamps of your commands too. > > They're fine. > > After a bunch of straces, I think the problem is different. As I > suspected from its intermittent nature, it's a race. > > When udevd starts up, it looks for an old database and converts it into > a new-style /run database. This takes nonzero time, and is done *after* > daemonization. Unfortunately, in the same time window it is quite > possible to fit a pair of 'udevadm trigger's and a 'udevadm settle': and > when udevadm settle kicks up and finds that udev hasn't even initialized > yet, what does it do? Well, unless I misread the code > udev_queue_get_queue_is_empty() returns 1 in this situation, so 'udevadm > settle' returns EXIT_SUCCESS, and boom. > > My evidence for this is very thin: it's no more than a hypothesis > really. My only evidence for this so far is that I haven't managed to > get the failure to happen unless I mkdir the old udev directories first > to force udev to do an old->new db conversion. It would be nice to > gather more data, but it's hard to do that without perturbing the race > :/ even an ls of /run slows it down enough that it doesn't happen > anymore. Hm, perhaps an echo would be fast enough, it's a shell > builtin after all... > > If I'm right (and I'm not sure I am, but it feels plausible), then I > suspect the only fix is to move the db conversion so that it happens > before daemonization. Hmm, the trigger should increase the kernel's current uevent seqnum. udev_queue_get_queue_is_empty() should see that there are events pending, not seen by udevd, and should make settle block until they are all handled. But maybe udev_queue_export_new() needs to move above the daemonize? It will create the initial queue file, that will make settle check for the udevd vs. kernel number. That could be the reason, for the race. 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
