unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Mark H Weaver <mhw@netris.org>
Cc: 35181@debbugs.gnu.org
Subject: bug#35181: Hydra offloads often get stuck while exporting build requisites
Date: Tue, 09 Apr 2019 12:54:20 +0200	[thread overview]
Message-ID: <87ftqrh2jn.fsf@gnu.org> (raw)
In-Reply-To: <87o95g5lpd.fsf@netris.org> (Mark H. Weaver's message of "Mon, 08 Apr 2019 15:40:51 -0400")

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> The source checkout currently being transferred for build 3432472
>>> (/gnu/store/…-font-google-material-design-icons-3.0.1-checkout) is 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?
>
> As far as I can tell, that's what seems to happen.
>
>> Did you try to check the status of the ‘nix-store’ and ‘guix offload’
>> processes on the head node?
>
> Here are the corresponding 'guix offload' processes:
>
> hydra@20121227-hydra:~$ ps auxwwf | head -1; ps auxwwf | egrep -B1 'off()load'

[...]

> root     14769  0.0  0.2 145668 10912 ?        SLsl Apr07   0:16  |       |   \_ /gnu/store/yihvhxv3xyyvl1m2cy1lnf1lyi9h76fk-guile-2.2.2/bin/guile --no-auto-compile /gnu/store/fkkjhida23k612naa9d4q6avqj5v3b28-guix-0.13.0-8.357ab93/bin/.guix-real offload x86_64-linux 3600 1 72000

The problem is that this is an ancient Guix.  In the meantime,
offloading has seen relevant changes, in particular things like commit
ed7b44370f71126087eb953f36aad8dc4c44109f which address stability issues
with Guile-SSH (ssh dist node) that was previously used.

I think we should upgrade Guix on hydra.gnu.org otherwise we’re likely
to end up chasing old bugs.

> The 'nix-store' processes seem to be stuck sleeping in 'read', if I'm
> interpreting the 'strace' output correctly:
>
> root@20121227-hydra:~# strace -p 8983
> Process 8983 attached - interrupt to quit
> read(3, ^C <unfinished ...>
> Process 8983 detached
> root@20121227-hydra:~# strace -p 14767
> Process 14767 attached - interrupt to quit
> read(3, ^C <unfinished ...>
> Process 14767 detached
>
>
> "netstat --inet --program" shows that the SSH connections are still
> open:
>
> root@20121227-hydra:~# netstat --inet --program | grep 'hydra\.net\.in\.tum\.'
> tcp        0      0 20121227-hydra.gn:53216 hydra.net.in.tum.de:ssh ESTABLISHED 14769/guile     
> tcp        0      0 20121227-hydra.gn:52434 hydra.net.in.tum.de:ssh ESTABLISHED 8985/guile      
> tcp        0      0 20121227-hydra.gnu.:www hydra.net.in.tum.:52104 TIME_WAIT   -               
> tcp        0      0 20121227-hydra.gnu.:www hydra.net.in.tum.:52103 TIME_WAIT   -               

This could be the kind of issue that we had with (ssh dist node).  It’s
hard to tell.

> I could easily believe that this problem is specific to
> hydra.gnunet.org, but even if that's the case, it would be good if
> offloading would reliably time out before days have passed.

That’s the case with commit a708de151c255712071e42e5c8284756b51768cd,
but again, the Guix installation on hydra may predate that.  :-/

Thanks,
Ludo’.

  reply	other threads:[~2019-04-09 10:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-07 16:41 bug#35181: Hydra offloads often get stuck while exporting build requisites Mark H Weaver
2019-04-07 16:45 ` Mark H Weaver
2019-04-07 17:31   ` Efraim Flashner
2019-04-08  6:28     ` Mark H Weaver
2019-04-08  7:13       ` Mark H Weaver
2019-04-08  8:19       ` Ludovic Courtès
2019-04-08 19:40         ` Mark H Weaver
2019-04-09 10:54           ` Ludovic Courtès [this message]
2019-04-09 18:09             ` Mark H Weaver
2019-04-09  1:06         ` Mark H Weaver
2019-04-09 10:56           ` Ludovic Courtès
2023-04-14 13:15           ` Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ftqrh2jn.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=35181@debbugs.gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).