On Mon, May 16, 2011 at 12:51, Kay Sievers <kay.sievers@xxxxxxxx> wrote: > 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. Commited a fix to git, that moves the creation of the queue file above the daemonize. Hopefully that's the race you are seeing. 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
