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

[Kay Sievers]

On Fri, Jul 12, 2013 at 4:49 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Fri, Jul 12, 2013 at 04:42:34PM +0200, Kay Sievers wrote:
>> 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.
>
> Ewww, yes, that's pretty nasty kernel behaviour/change there :-(

The sequence numbers were done to track queued events in the host and
to wait for them, having the netns hack "stealing" the devices in /sys
and the uevents by filtering seems to work ok, but stealing our
sequence numbers is pretty nasty. :)

Yeah, we need to find out what other options we have. Maybe there is a
way to reliably work around that issue in udev, but at this moment I
don't really see how ...

Kay