[systemd-devel] udevadm settle hangs due to veths in seperate network namespaces

[Kay Sievers]

On Fri, Jul 12, 2013 at 3:51 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> We're hitting a problem in libvirt where 'udevadm settle' will get stuck
> in a loop until it eventually times out. Eventually we realized this
> happens when we have any LXC containers active with veth devices in a
> separate network namespace.
>
> It is quite easy to reproduce the hang. In one terminal session start
> a new network namespace:
>
>   # unshare  --net /bin/sh
>   sh-4.2# echo $$
>   30718
>
> Now in another terminal create a veth pair, and move one of the pair
> into the network namespace:
>
>   # ip link add name FOO type veth peer name BAR
>   # ip link set FOO netns 30718
>
> Now udevadm will hang:
>
>   # udevadm settle
>
> until it times out after 2 minutes.
>
> Looking at the udevadm code I discovered that
>
>   udev_queue_get_queue_is_empty
>
> will never return true if there is any veth device that has been moved
> into a separate network namespace.
>
> Adding some debugging I can see that the variable 'seqnum_udev' is
> forever less than 'seqnum_kernel' in this scenario.
>
> Any ideas on how to solve this problem with udevadm settle ?

Hmm, we just don't really support running udev inside of containers.
Hotplug and full OS containers have did never get any real attention
from udev running inside container setups.

If that needs to work, quite some assumptions would need to be changed
in the udev code. I don't think there is at the moment any clean
solution to the above mentioned problem. The network namespaces and
the devices in /sys, and the associated uevents are just a pretty
dirty hack in the kernel, which doesn't make it as easy as in the host
to work with.

Maybe it could be made working for network devices, for real device
nodes inside the container it will probably never really work, because
it depends on devtmpfs, and devtmpfs should only be managed by the one
udev running in the host.

Kay