On Mon, 2 Jul 2018 12:10:34 +0200 Paul Gevers <elb...@debian.org> wrote:
> On Sat, 21 Apr 2018 12:15:28 +0200 =?utf-8?q?Ferenc_W=C3=A1gner?= > <wf...@debian.org> wrote: > >> --- /usr/bin/autopkgtest-build-lxc 2018-04-18 10:44:36.000000000 +0200 >> +++ /home/wferi/autopkgtest-build-lxc 2018-04-19 18:36:05.937432180 >> +0200 >> @@ -123,7 +123,7 @@ >> } >> >> # wait until a systemd based container has networking >> - if ! echo '[ ! -d /run/systemd/system ] || systemctl start >> network-online.target' | timeout 60 lxc-attach --name=$1 -- sh -e; then >> + if ! echo '[ ! -d /run/systemd/system ] || systemctl start >> network-online.target' | lxc-attach --name=$1 -- sh -e; then >> echo "Timed out waiting for container to start >> network-online.target" >&2 >> exit 1 >> fi >> >> That is, simply removing "timeout 60". > > I fear that this may work for you, but isn't robust. I think we want > some form of timeout there to prevent infinite hang-ups. > >> Maybe an alternate solution could be designed by installing a systemd >> service in the guest to run the setup-testbed and customize scripts >> without requiring these lxc-attach commands. Just an idea, I'll be >> happy with any fix you prefer. > > I think this isn't a great solution either, as that means we depend on > systemd in the guest. I don't think we should (yet?). Hi Paul, What about forgetting about network-online.target and similar hacks (https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ doesn't think about it highly) altogether, and instead configuring apt-get for a dozen or so retries (that seems to be the first command in setup-testbed requiring network access). The build process is rather noisy already, so this could be a simple init-system-agnostic solution. -- Regards, Feri
