After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 740526 - [review] lr/no-udev: Fix handling of hardware devices inside a container
[review] lr/no-udev: Fix handling of hardware devices inside a container
Status: RESOLVED DUPLICATE of bug 731014
Product: NetworkManager
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-11-22 09:53 UTC by Lubomir Rintel
Modified: 2015-01-26 16:52 UTC
See Also:
GNOME target: ---
GNOME version: ---



Comment 1 Dan Winship 2014-11-24 15:34:57 UTC
> 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?
Comment 2 Dan Williams 2014-11-24 16:27:09 UTC
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.
Comment 3 Lubomir Rintel 2014-12-01 18:10:17 UTC
(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?
Comment 4 Dan Williams 2015-01-23 16:09:54 UTC
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?
Comment 5 Thomas Haller 2015-01-23 17:17:07 UTC
(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.
Comment 6 Lubomir Rintel 2015-01-26 16:52:16 UTC
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 ***