Hey, the underlying problem described below, is in no way specific to systemd, it applies to all modern systems and services, existing ones, or ones not even developed. The udev systemd service files for udev do no longer pull-in the barrier 'udevadm settle'. The udev coldplug run is executed fully asynchronously in the background along with many other services, and no other service will be blocked by default, waiting for udev to populate /dev. That means: non-hotplug-aware services are likely to break. Services which assume a static /dev, rely on scanning /dev and finding "all" devices at a certain point in time, are required to explicitly pull-in udev-settle.service to paper-over their inability to cope with a dynamic system. It will block the broken service until udev's coldplug run has finished and /dev is populated with all devices known at that time. It's 2011 and services should cope with hotplug, devices coming and going at any time, and a constantly changing and re-configuring environment. No service which wants survive the next years of Linux evolution should depend on the udev-settle.service barrier though, please fix your stuff, or the reality might go on without you. :) There is libudev, which connects your service to meaningful event for news devices, device changes, and allows you to enumerate all currently existing devices. Subscribing to events before enumeration is started will make sure not to miss anything, and to propagate later changes into the service. All that even works from python, java, mono, javascript, ... programs, so there is no excuse anymore to continue to do any of the much-too-simple things we all did in the past. Just stop making assumptions like: "booting has finished" or "all devices are there" -- that never really was in the past, and it will never be true in the future. Thanks, 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