> On Fri, Feb 16, 2018 at 11:52:05AM +0000, Iain Lane wrote:
> > On Thu, Feb 15, 2018 at 09:55:47PM +0100, Martin Pitt wrote:
> > > Hello Iain, all,
> > > Iain Lane [2018-02-15 18:48 +0000]:
> > > > There's a patch attached here which fixes the problem for me. I'm not
> > > > sure if there's a better way to do this - basically it starts
> > > > network-online.target and waits for it to become active, with a timeout.
> > > > Review appreciated.
> > > I wouldn't pick on any of these: network-online.target is a sloppily defined
> > > shim for SysV init backwards compatibility, and may not ever get started (in
> > > fact, that's the goal ☺); and the container might not use networkd, so I
> > > wouldn't use s-n-wait-online either. I think querying
> > Interesting. I thought that it was the systemd way to say 'I am online
> > now' --- i.e. nm-online or systemd-networkd-wait-online, which is the
> > question I wanted to get a positive answer to. I can see that the SysV
> > implementation isn't great, but it's not clear to me that it was ill
> > defined for this case.
> > > [ -n "$(ip route show to 0/0)" ]
> > This is better though, and works too. Please take a look at the attached
> > patch. Thanks! :-)
> 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.
> I think the network-online.target is the better thing to key on.
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.
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel