On May 20, 2015 9:48 AM, "Tom Gundersen" <t...@jklm.no> wrote: > > On Tue, Apr 21, 2015 at 11:59 PM, Nick Owens <misch...@offblast.org> wrote: > > hello tom, > > > > On Mon, Apr 20, 2015 at 2:32 PM, Tom Gundersen <t...@jklm.no> wrote: > >> On Fri, Apr 3, 2015 at 12:48 AM, Michael Marineau > >> <michael.marin...@coreos.com> wrote: > >>> On Thu, Apr 2, 2015 at 3:08 PM, Nick Owens <misch...@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 < arvidj...@gmail.com> wrote: > >>>>> On Wed, Mar 25, 2015 at 11:49 PM, <misch...@offblast.org> wrote: > >>>>>> From: mischief <misch...@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.
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel