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

Kay Sievers kay at vrfy.org
Fri Jul 12 07:42:34 PDT 2013


On Fri, Jul 12, 2013 at 4:21 PM, Kay Sievers <kay at vrfy.org> wrote:
> On Fri, Jul 12, 2013 at 4:14 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
>> On Fri, Jul 12, 2013 at 04:10:35PM +0200, Kay Sievers wrote:
>
>>> 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.
>>
>> This example is *not* running udev in the container. The 'udevadm settle'
>> command above is being run in the primary OS. IOW, the fact that the
>> container has a network namespace with a veth, is breaking udevadm in
>> the host.
>
> Oh, interesting. I thought you meant running 'settle' inside the container.
>
> That, then sounds like something we should be able cope with. I'll
> have a look now ...

The kernel uevents generated inside the network namespace use the same
single global sequence number as the host, but the  events for the
in-namespace devices are simply filtered out not to show up in the
host.

Settle expects to see *all* sequence numbers to wait for, and does not
accept holes in the sequence.

Hmm, at this moment, I have no idea how that should work, we cannot
easily find out that these events will never show up in the host and
we should not wait for them.

The uevent filter hack in the kernel maybe should just be changed to
not allocate sequence numbers of the *host* inside the namespace, and
always compose the events inside the namespace with SEQNUM=0.

Kay


More information about the systemd-devel mailing list