[systemd-devel] [PATCH] networkd: fix systemd-networkd-wait-online with multiple NICs
teg at jklm.no
Wed May 20 09:48:24 PDT 2015
On Tue, Apr 21, 2015 at 11:59 PM, Nick Owens <mischief at offblast.org> wrote:
> hello tom,
> On Mon, Apr 20, 2015 at 2:32 PM, Tom Gundersen <teg at jklm.no> wrote:
>> On Fri, Apr 3, 2015 at 12:48 AM, Michael Marineau
>> <michael.marineau at coreos.com> wrote:
>>> On Thu, Apr 2, 2015 at 3:08 PM, Nick Owens <mischief at offblast.org> wrote:
>>>> hi, sorry for the delay.
>>>> from http://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html:
>>>> "By default, it will wait for all links it is aware of and which are
>>>> managed by systemd-networkd.service(8) to be fully configured or
>>>> failed, *and for at least one link to gain a carrier.*".
>>>> the import part here is the end of the sentence. without this patch,
>>>> systemd-networkd-wait-online will block until all configured
>>>> interfaces have carrier.. you can reproduce this by running
>>>> systemd-networkd in qemu with two ethernet interfaces, and issue 'info
>>>> network' and then 'set_link <if> down' to simulate no carrier. then
>>>> you can run systemd-networkd-wait-online, and observe that it will
>>>> block until both interfaces are up, not just one.
>>>> On Wed, Mar 25, 2015 at 10:53 PM, Andrei Borzenkov <arvidjaar at gmail.com> wrote:
>>>>> On Wed, Mar 25, 2015 at 11:49 PM, <mischief at offblast.org> wrote:
>>>>>> From: mischief <mischief at offblast.org>
>>>>>> when checking interface status, systemd-networkd-wait-online
>>>>>> will continue to wait if any interface is still configuring or
>>>>>> being processed by udev. this patch allows it to return if any
>>>>>> one interface is degraded/routable, as per the manual.
>>>>> But current behavior is exactly what manual says: "By default, it will
>>>>> wait for all links it is aware of and which are managed by
>>>>> systemd-networkd.service(8) to be fully configured or failed". Or do I
>>>>> miss something?
>>> It is worth noting that there may be some issues with tracking
>>> interface states in networkd, there appear to be ways to get an
>>> interface stuck in a 'configuring' state despite the fact that the
>>> interface has no network config and/or has no carrier.
>> Do you have any more info on this? Can you reproduce with current git?
>> There was a fix after the last release which should fix a problem with
>> enumerating devices.
> the original issue was discussed at
> https://github.com/coreos/bugs/issues/279. i just tested commit
> is our default for networkd. it seems logical that given this config,
> systemd-networkd-wait-online would wait for all of the dhcp
> interfaces, no matter how many.
> however, i'm not sure what use case there is for this. it seems like
> there's no way to wait for any one nic to be routeable/configured
> without knowing its name ahead of time.
Correct. I mean, waiting for the system coming online like this is
mostly a legacy thing, so we support this in a relatively limited way.
Anything modern better explicitly listen for rtnl events and act
> another instance of this problem is having a bridge like
> and run 'systemctl restart systemd-networkd;
> /usr/bin/systemd-networkd-wait-online'. systemd-networkd-wait-online
> will not return. is this intended behavior?
Hm, I'm not able to reproduce this. Can you still reproduce with git
HEAD? If so what are the other config files that are applied, and what
is the output of networkctl whilst wait-online is hanging?
More information about the systemd-devel