udevadm --settle

DJ Lucas dj at linuxfromscratch.org
Thu May 12 00:09:00 PDT 2011

On 05/11/2011 11:25 PM, Bruce Dubbs wrote:
> DJ Lucas wrote:
>> After updating from udev-165 to udev-168, I ran into a timing issue
>> with settle using tmpfs for /dev. My swap partition failed to mount
>> because the device node was not present. No other changes than those
>> made to the bootscripts and FS layout to account for /run. I rebooted
>> a few more times to see that the problem was consistent. One other
>> variable is that I'm using new bootscripts (which _should_ provide a
>> very minimal speed increase), but order is the same as stock LFS.
>> Following a hint I found on a Debian mailing list claiming that
>> devtmpfs was faster, I enabled devtmpfs, commented out the /dev mount
>> in the udev script, and sure enough, the problem resolved itself.
>> Now, that said, I'm probably a bit of a minority with so many
>> partitions on my disks and this surely has some weight, however,the
>> results are consistantly reproducable on my system. Why settle is not
>> doing what it is intended to do is beyond me. We are only discussing
>> a very small amount of time, a few ms at best here, so I see a couple
>> of options:
>> 1. The obvious one (at least to me) is to force the use of devtmpfs
>> as upstream has intended, and remove the /dev mount from the udev
>> script.
> I don't use either.  I prefer a persistent /tmp, but that's just me.  If
> I download a file, say a pdf, from the browser, it saves it to /tmp even
> though it goes directly to the pdf reader.  I'd rather it takes up disk
> than ram and I prefer it to stay in /tmp until I specifically delete it.
> Yes, I modified cleanfs.
I don't think we are referring to the same thing. DEVTMPFS provides a 
minimal /dev (a tmpfs mount) immediately after the kernel mounts the 
rootfs. Aparently it is a little more populated than I had thought as 
/dev/sd* devices exist there which is why it worked for me...and 
probably would for most users (except those really well versed in udev 
tricks using device by id or labels and such). I prefer simplicity a 
good part of the time, but there are many exceptions. Fortunately, 
device naming is not one of those exceptions.

- Device Drivers
   - Generic Device Drivers
    ()  path to uevent helper
    [*] Maintain a devtmpfs filesystem to mount at /dev
    [*]   Automount devtmpfs at /dev, after the kernel mounted the rootfs

>> 2. Add a sleep to the end of the udev script (how long?).
> Two seconds has been reported as working.
>> 3. Changing bootscript order to put checkfs before swap should give
>> enough time for udev to get the coldplug events handled and written
>> to the tempfs.
> That seems like a reasonable approach, but it may not be enough
> depending on the size and number of the partitions and if they are clean
> or not.
>> 4. It is a local issue and my troubleshooting skills are not up to
>> par. ;-)
> I doubt it.
> udev is a bit troublesome.  I suppose there could be a custom udev rule
> to automatically mount the swap partition when, say /dev/sda3, becomes
> available.  That's probably not really satisfactory though.
This is what upstream wants. See below...
> Another thought would be to do something like:
> while ! -b /dev/sda3; do sleep 1; done
> swapon -a
settle has an option for just that, but I don't think it is the right 
fix. Seems to me that something must have been broken in trigger, else, 
given the reliable reproduction of my current problem and the 
reliability of the work around, I would have seen the same issue well 
before now.
> The problem seems to be inherent with dynamic devices.  If you try to do
> something before the driver tells udev it's there, the operation will
> fail.  It's a race condition.  I don't see a solid solution that will
> work in every case.
>     -- Bruce
Sure there is...a fully event driven init as Bryan described earlier. I 
just don't find that to be transparent enough for my taste, nor udev 
quite mature enough just yet (as evidenced by this very issue), though 
it is getting there slowly but surely.

-- DJ Lucas

This message has been scanned for viruses and
dangerous content, and is believed to be clean.

More information about the lfs-dev mailing list