On 8/7/09, Nigel Kukard <nkukard@xxxxxxxx> wrote: > >>> >>> Trying to figure something out here, using the following I'm seeing a >>> delay in the creation of block devices in /dev ... >>> >>> # trigger the sorted events >>> echo -e '\000\000\000\000'> /proc/sys/kernel/hotplug >>> >>> rm -fr /dev/.udev> /dev/null 2>&1 >>> mkdir -p /dev/.udev> /dev/null 2>&1 >>> /sbin/udevd >>> >>> # Not entirely sure what this is for >>> /sbin/udevadm control --env=STARTUP=1 >>> /sbin/udevadm trigger >> >>> /sbin/udevadm settle >> >> settle should have waited until all events have been processed > > Does this mean fully processed or just received? I asked on > #udev/irc.freenode.net and was told that settle only waits until udev > had received them. It does wait until events are "fully processed". The problem is that this will only apply to the events generated directly by udevadm trigger. USB devices may turn up late to the party for various reasons. Lurking on LKML it sounds like it _might_ be possible to fix the USB issue. AFAIK no-one is working to support this for userspace though. > The only reason it worked before was because of the speed improvements > made recently. Yup. >>> # Nor sure what this does >>> /sbin/udevadm control --env=STARTUP= >>> >>> >>> I think my problem is, while all the events have been sent to udevd >>> there is a delay if I do a "fsck LABEL=root" straight on say the next >>> line, a "ls" shows that none of the block devices exist until a second >>> or two later. A sleep 5 before my "ls" works around this and the block >>> devices show up. >>> >>> Any ideas how I can determine once all udev events have finished >>> processing so I can continue boot? >> >> check would look like: >> /sbin/udevadm settle --timeout=0 || echo "Still not all udev events >> processed" >> >> waiting should be: >> /sbin/udevadm settle > Same result on both. > > I went further and wrote a small C app to wait for the udev event, this > works 100%. I run the C app in the background before I run trigger & > settle, then do a "wait" until it returns. > > -N I think everybody else just loops waiting for the device node to appear. So technically you may have a more advanced solution :-). Usually you also want a timeout in case something goes wrong. Depending on the system you can e.g. drop to an emergency shell or just print an error message. Alan -- 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
