Summary: | udev 197 network device renaming race condition | ||
---|---|---|---|
Product: | systemd | Reporter: | Alexei Robyn <shados> |
Component: | general | Assignee: | systemd-bugs |
Status: | RESOLVED WONTFIX | QA Contact: | systemd-bugs |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Alexei Robyn
2013-01-28 10:42:33 UTC
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.