Currently, udev is not guaranteed to have completed renaming the initial set of network devices to persistent names before network.target and it's Wants are run. This can cause a race condition where a network configuration unit file will fail because it is attempting to configure devices that to do not (yet) exist. This can be be worked around by using an instantiated unit file and specifying 'After=sys-subsystem-net-devices-%i.device', but this would have to be done for every initial network configuration unit file. Additionally, this is not a valid solution for unit files that may need to configure multiple interfaces based upon configuration information elsewhere. Such services would each need to handle this case themselves, which seems like an unnecessary duplication of functionality across the system. Having read http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget, I understand the difficulty in choosing a good general default for the meaning of "the network is up", but "initial attached network devices have their persistent names" does seem like a minimal prerequisite; I'm having trouble coming up with a sane meaning of "the network is up" that doesn't depend on it. For some extra context, I'm coming from: https://bbs.archlinux.org/viewtopic.php?id=156956
Hmm? The network interface naming takes place in udev rules, so that clients listening to that will never see the original name at all. I figure you are using some tool that watches netlink only, but not udev for devices appearing and then configures them? It really shouldn't do that. Watching netlink is fine, but apps must also take udev into account and not up the device (in fact, not touch it at all) before the udev rules finished with it. udev rules might not just set the name of a device, but alter all kinds of parameters on the device, and hence apps should never take possesion of the iface before waiting for udev. NetworkManager gets this all right. What network management are you using? Most likely that software should be fixed to watch libudev.
This looks like the same issue: https://bugs.freedesktop.org/show_bug.cgi?id=59610 if this is also about dhcpcd, then we should close this one as duplicate....
(In reply to comment #2) > This looks like the same issue: > > https://bugs.freedesktop.org/show_bug.cgi?id=59610 > > if this is also about dhcpcd, then we should close this one as duplicate.... It's not about dhcpcd per se, it's about simple networking unit files (straight `ip` commands configuring a static address, for instance). Your point about network configuration tools is true, but you don't always necessarily want to use them if your network configuration is pretty trivial. For that kind of situation, it'd be a lot nicer if you could just trigger off of network.target and not have to worry about writing code to wait on udev's renaming of boot-time interfaces to finish. True, this kind of simplistic configuration approach isn't exactly durable, but it does work well in a lot of situations and is useful during initial setup and any other circumstance where you might not have access to more flexible tools. If you haven't read it already, the Arch forums link at the bottom of my report may help illuminate things.
Looks like sys-subsystem-net-devices-<device>.device should be symlinked into /etc/systemd/system/network.target.wants for this specific use case. There isn't much that udev can do, because "initially attached network devices" is an undefined concept, especially with hot-pluggable hardware. udev has no way of knowing that enp0s29u1u2u2 will be configured by some custom script, so it must be told explictly to wait, by adding Wants= dependencies or similar. I think that this qualifies as not a bug.
I am convinced that this is really something to fix in the networking scripts (i.e. they need to watch network devices only via udev, and not otherwise), and not systemd.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.