[systemd-devel] [PATCH] networkd: fix systemd-networkd-wait-online with multiple NICs

[Michael Marineau]

On May 20, 2015 9:48 AM, "Tom Gundersen" <teg at jklm.no> wrote:
>
> 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.
> >>>>
> >>>> nick
> >>>>
> >>>> 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
> > cffacc741cb79f63999720525ceaa65aae01a542.
> >
> >
https://github.com/coreos/init/blob/master/systemd/network/zz-default.network
> > 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
> accordingly.
>
> > another instance of this problem is having a bridge like
> >
> > [NetDev]
> > Name=br0
> > Kind=bridge
> >
> > 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?

I haven't retested HEAD yet but up through 219 it would report 'no-carrier
configuring' which seems bogus since it shouldn't be configuring an
interface in such a state and there is no .network config to apply to the
interface either. We have seen similar looking networkctl output for
physical interfaces too but since several different states get squashed
into 'configuring' I'm not sure if it is the same situation, it was just
easier to demo with a .netdev and bridge. Interestingly no other mechanism
for creating a bridge (ip or brctl) got it into the same state but I'm not
sure why.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150520/afdd480b/attachment.html>