From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#35181: Hydra offloads often get stuck while exporting build requisites Date: Mon, 08 Apr 2019 10:19:18 +0200 Message-ID: <87pnpw29kp.fsf@gnu.org> References: <87mul17oo2.fsf@netris.org> <87imvp7ogv.fsf@netris.org> <20190407173105.GB1337@macbook41> <87ef6d6mdn.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:45663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDPVb-0006AI-Au for bug-guix@gnu.org; Mon, 08 Apr 2019 04:20:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hDPVa-0002mV-Er for bug-guix@gnu.org; Mon, 08 Apr 2019 04:20:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:35429) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hDPVa-0002mK-9Q for bug-guix@gnu.org; Mon, 08 Apr 2019 04:20:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hDPVZ-0007pW-V9 for bug-guix@gnu.org; Mon, 08 Apr 2019 04:20:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87ef6d6mdn.fsf@netris.org> (Mark H. Weaver's message of "Mon, 08 Apr 2019 02:28:41 -0400") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Mark H Weaver Cc: 35181@debbugs.gnu.org Hi Mark, Mark H Weaver skribis: > The source checkout currently being transferred for build 3432472 > (/gnu/store/=E2=80=A6-font-google-material-design-icons-3.0.1-checkout) i= s 176 > megabytes uncompressed, as measured by "du -s --si", which is not > precisely same as NAR size, but hopefully close enough for a rough > estimate. As I write this, build 3432472 been stuck here for 24 hours > 15 minutes. Even if the average transfer rate were 4 kilobytes per > second, it should have been done in half that time. This is weird, could it be that data transfers get stuck somehow? Did you try to check the status of the =E2=80=98nix-store=E2=80=99 and =E2=80= =98guix offload=E2=80=99 processes on the head node? I just checked and apparently this package builds fine on berlin. Thanks for investigating, Ludo=E2=80=99.