From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6824111115797004288 X-Received: by 2002:a19:7f17:: with SMTP id a23mr748739lfd.38.1588917457906; Thu, 07 May 2020 22:57:37 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ac2:5de8:: with SMTP id z8ls71741lfq.4.gmail; Thu, 07 May 2020 22:57:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzuX3Gb+rRggKgotsddVg7ESf74rCxMEgxdR7kmSpYJ7dYBW66/YebHPVbTcTqed7ghQd/v X-Received: by 2002:ac2:4910:: with SMTP id n16mr741775lfi.35.1588917457203; Thu, 07 May 2020 22:57:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588917457; cv=none; d=google.com; s=arc-20160816; b=b4yPguR+lnvyIad53Sqmu5ohk7K3Zs+hSJlpW6VpUHUCu/h2+iFLJ1hY0VYTqPNeOh MuzhpbPEqjxTwDyVHPxUQsVj5Nol3rjG3Mwe+mMv4+TkdBIJKd910wGD9tmD6jediIwz EcoxpcEyn7icKnmaL5PDukoRAYzi+4DKU+eYDuVov1k1FwGTuUDpBu0rq24xwUS7zifM ZkkDCZUlUir2/B06cAeU3nK8ivMXBpXkJINPXjKNahzuj7NDJOcBUqd6HvYzkJzwSxr2 UcsP6u04K2h5YRJT6jlniXASxL1IkXIgTWcItamAl8oYhS5mnBTFaVCYSwD1m7N+1JOz hwNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=BCQXw6MMdR4i3GUUqBnDt268sMJOjkjUXFs0bFq4uDY=; b=J33eVm/yidjP7A3sRzH2iHhqPpv9LA+V2mcVkGbdPnDebUqsvgvzHUq1JrMnyv7gys VYbSRIy+2EBqNTcqSi2zB7SkiZurob6jJYyI1ADeNYBuVJItNrk2SLBPqJS07JW5/tyB MryNnGrAqqrPlUJDl7GSW1udr1Ge4bK6Ok9O4yrlBqng3BY/X3Uljp4LXWrgkTIR6YqX Qe5TKwnJmeFdU9ArmS8X6OtRZcVgcZd14n3dLjRBFkaNuNNcLc4jPEnozaiB3km8Q+aj hcDvetEi3ZkbZPyOvtiKhZT4VlkWD1Qe7MHHzQeNIdclufw3s9V+sOMOsgllDzbxBJtd 80Ww== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id f25si31081lfc.3.2020.05.07.22.57.37 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 22:57:37 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 0485vaOk029905 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 8 May 2020 07:57:36 +0200 Received: from [167.87.32.232] ([167.87.32.232]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 0485vYX8005385; Fri, 8 May 2020 07:57:35 +0200 Subject: Re: [RFC][PATCH] rootfs: Retry downloads 3 times To: Henning Schild Cc: isar-users References: <1d96541b-1263-773c-d340-35b0c73cb257@siemens.com> <20200507201357.5d24f91b@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: Date: Fri, 8 May 2020 07:57:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200507201357.5d24f91b@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: V8TlrnjtB30N On 07.05.20 20:13, Henning Schild wrote: > The idea is good but the patch is incomplete. > > To find all places where we download you might want to look at bitbake > fetchers in general - do they have a retry count? > > Is there a variable controlling that? As explained in the commit log, it's not consistent in bitbake. At least wget has such a retry counter. In other cases, bitbake seems to quickly fall back to mirrors and fail. > > After that look at all debian downloaders. You will find them when > looking for "download-only", "apt-get update" any maybe more. They > should use the central bitbake count or switch if available. > > Your patch found one of many "download-only" and ignores bitbake. Might > be the most likely ... but we should try to be consistent. Yes, we likely also need this when fetching build deps. All images are covered this way already, I also checked debootstrap but found no retry switch there. So the result will remain "best effort" in general. Therefore, I was also wondering if it's worth it. Background was may lengthy attempt yesterday to install a complex image from snapshot.debian.org. The "solution" (that avoided a first complete local mirror) was to throttle the download bandwidth to some 1 MBit/s. Maybe there was just one bad mirror on the other side, but it constantly killed the image installed. Retrying was a futile attempt there, but I've also seen (few) nightly builds in the past that stumbled over individual packet downloads where this might have helped. Jan > > Henning > > Am Thu, 7 May 2020 16:36:18 +0200 > schrieb Jan Kiszka : > >> From: Jan Kiszka >> >> Avoids failing a complete rootfs installation in case of a short >> hick-up. >> >> Signed-off-by: Jan Kiszka >> --- >> >> Does something like this make sense? Do we have more places? >> We have a retry of 2 on wget bitbake fetches, e.g. (via >> FETCHCMD_wget). >> >> meta/classes/rootfs.bbclass | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/meta/classes/rootfs.bbclass b/meta/classes/rootfs.bbclass >> index 806e824c..afec1cbc 100644 >> --- a/meta/classes/rootfs.bbclass >> +++ b/meta/classes/rootfs.bbclass >> @@ -123,7 +123,7 @@ rootfs_install_pkgs_download[weight] = "600" >> rootfs_install_pkgs_download[isar-apt-lock] = "release-after" >> rootfs_install_pkgs_download() { >> sudo -E chroot '${ROOTFSDIR}' \ >> - /usr/bin/apt-get ${ROOTFS_APT_ARGS} --download-only >> ${ROOTFS_PACKAGES} >> + /usr/bin/apt-get ${ROOTFS_APT_ARGS} -o Acquire::Retries=3 >> --download-only ${ROOTFS_PACKAGES} } >> >> ROOTFS_INSTALL_COMMAND_BEFORE_EXPORT ??= "" > -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux