GNOME Bugzilla – Bug 740526
[review] lr/no-udev: Fix handling of hardware devices inside a container
Last modified: 2015-01-26 16:52:16 UTC
Just this fix: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=lr/no-udev&id=09248714525cfa07e5b665af8855fd6011300411
> Remove the software link special case, the software links now won't wait for > udev initialization as well. It seems to do the opposite; *currently*, software links don't wait for udev initialization, but you're removing that special case, so now they will have to. >+ if (access ("/sys", W_OK) == 0) It feels a little bit hackish to be assuming that /sys being unwritable corresponds to udev not running. Is there no other way we can determine that?
libudev itself does this to check if udev is present or not: /* * We do not support subscribing to uevents if no instance of * udev is running. Uevents would otherwise broadcast the * processing data of the host into containers, which is not * desired. * * Containers will currently not get any udev uevents, until * a supporting infrastructure is available. * * We do not set a netlink multicast group here, so the socket * will not receive any messages. */ if (access("/run/udev/control", F_OK) < 0 && !udev_has_devtmpfs(udev)) { log_debug("the udev service seems not to be active, disable the monitor\n"); group = UDEV_MONITOR_NONE; } else group = UDEV_MONITOR_UDEV; and udev_has_devtmpfs() gets the mountid fro /dev, then reads /proc/self/mountinfo and looks for the mountid. If that mountid starts with "devtmpfs" then it assumes udev is running. I can't find any other way of using libudev or gudev that will tell us if udev is running or not. Note that systemd-networkd uses a different method, src/shared/virtual.c::detect_container() which is icky in it's own way, at least for us.
(In reply to comment #1) > > Remove the software link special case, the software links now won't wait for > > udev initialization as well. > > It seems to do the opposite; *currently*, software links don't wait for udev > initialization, but you're removing that special case, so now they will have > to. I need to fix the wording, I'm missing a conditional there. What I meant is "they won't wait in case udev is not running". > > >+ if (access ("/sys", W_OK) == 0) > > It feels a little bit hackish to be assuming that /sys being unwritable > corresponds to udev not running. Is there no other way we can determine that? That is how the udev service determines if it will start or not. (In reply to comment #2) > libudev itself does this to check if udev is present or not: > > /* > * We do not support subscribing to uevents if no instance of > * udev is running. Uevents would otherwise broadcast the > * processing data of the host into containers, which is not > * desired. > * > * Containers will currently not get any udev uevents, until > * a supporting infrastructure is available. > * > * We do not set a netlink multicast group here, so the socket > * will not receive any messages. > */ > if (access("/run/udev/control", F_OK) < 0 && > !udev_has_devtmpfs(udev)) { > log_debug("the udev service seems not to be active, > disable the monitor\n"); > group = UDEV_MONITOR_NONE; > } else > group = UDEV_MONITOR_UDEV; > > and udev_has_devtmpfs() gets the mountid fro /dev, then reads > /proc/self/mountinfo and looks for the mountid. If that mountid starts with > "devtmpfs" then it assumes udev is running. > > I can't find any other way of using libudev or gudev that will tell us if udev > is running or not. Note that systemd-networkd uses a different method, > src/shared/virtual.c::detect_container() which is icky in it's own way, at > least for us. I don't know... /run/udev/control does not exist with older udev versions. If we didn't care about them, would it be sufficient to look there, or is the devtmpfs magic needed?
It seems this bug is actually now a dupe of bug 731014 now? I think the solution in that bug would work for this bug too, potentially, since instead of NM attempting to auto-detect container behavior, the container setup would include installing the right udev rules to get NM to fully manage the veth in the container?
(In reply to comment #4) > It seems this bug is actually now a dupe of bug 731014 now? I think the > solution in that bug would work for this bug too, potentially, since instead of > NM attempting to auto-detect container behavior, the container setup would > include installing the right udev rules to get NM to fully manage the veth in > the container? Lubomir said, that in the usual use-case inside containers there is no udev running to process the rules. While the script that sets up the container environment could fake the properties, it is a bit more complicated then dropping udev-rules. I just say, a good default behavior is still desirable, even if it can be overwritten by udev properties.
Added the commits to bug #731014 branch; a more complex solution to the problem. *** This bug has been marked as a duplicate of bug 731014 ***