[no subject]

 - DNS setup is complete
 - all "required" network interfaces (implementation-defined) have completed
   their configuration
 - if no network interfaces are defined to be "required", then at least one
   interface is up

This is broad enough to encompass everything from VPNs to captive portals to
proxy-only networks, and provides a clear separation of responsibilities.

I'd be happy to discuss this somewhere more on-topic than autopkgtest-devel
:-)

>   - These tools should also work with Debian containers, which in theory
>     could also run sysvinit.  This is also the reason why they still use
>     `runlevel` instead of `systemctl is-system-running` or something
>     similar.

Sure, but in principle, once you've reached runlevel 2 under sysvinit you
can rely on the network being up because that's part of the definition of
the runlevel.  So the systemd code doesn't need to have a sysvinit
equivalent.

On Mon, Feb 19, 2018 at 09:42:25AM +0000, Iain Lane wrote:
> On Fri, Feb 16, 2018 at 08:15:35PM +0100, Julian Andres Klode wrote:
> > On Fri, Feb 16, 2018 at 11:12:32AM -0800, Steve Langasek wrote:
> > > [?? ]
> > > Actually no, this is racy, because the route comes up before DNS resolution
> > > is in place.
> > > 
> > > It's also not forwards-compatible with ipv6-only deploys.

> Fair point. I could add an `ip -6' equivalent.

> > > I think the network-online.target is the better thing to key on.

> Ho hum. Well then, I've now made patches for both ways. Can you and
> pitti please decide what is actually better between you? I'll not bother
> writing any more code until then. :-)

> BTW, while I experience a network-is-not-up race most times in current
> autopkgtest, I didn't experience it at all with pitti's suggestion so at
> least for me the race is won all of the time.

Martin's approach definitely *narrows* the race, but it's still there.

> I'm not sure if network-onilne.target's semantics are enough for this
> either?

network-online.target's semantics are either a) enough or b) critically
buggy, since other software depends on them the same way I propose that
autopkgtest would.

But notably, /lib/systemd/system/systemd-resolved.service declares
'Before=network-online.target' - because of issues found and fixed when it
did not.

(That's in Ubuntu.  It appears the Debian package has this as
'Before=network.target', which is strictly before network-online.target.)

> > I think we should just grep the apt output and retry if it fails with
> > connection error messages. This should be fine until I have an improved
> > solution in apt itself, one of

> > (1) "there are no transient errors"
> > (2) one source must have updated
> > (3) all sources must have updated

> > Not sure on details. Could be an option for all three.

> autopkgtest calls apt all over the place. Some of them are covered by
> retry loops already, but I'm not super excited about hunting down the
> rest until we can do it in a clean way or, even better from my POV, if
> apt were to retry itself a few times before giving up.

> It seems sensible to me to try not do work until we think the network is
> "up" enough to contact our apt sources anyway.

+1.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20180220/ff975f61/attachment.sig>