Re: Error handling when 'guix substitute' dies

[Ada Stevenson <adanskana@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2882 bytes --]

Hi Lars,

On Tue, Apr 2 2024 at 10:42:18 AM +0200, Lars Bilke <lars.bilke@ufz.de> 
wrote:
> Dear Ludo,
> 
> I ran the command in a loop on 4 machines for around 2 hours doing 1 
> request per machine per second but no errors occured...
I did a similar thing. No errors at all.
However, I was reconfiguring my system at uni yesterday after the 
gnome-team merge and it was happening a lot! I wonder if it's something 
to do with the server? I don't know enough about networking to really 
theorise, haha.
> 
> On 29 Mar 2024, at 16:10, Ludovic Courtès wrote:
> 
>>  Hello,
>> 
>>  Ada Stevenson <adanskana@gmail.com <mailto:adanskana@gmail.com>> 
>> skribis:
>> 
>>>>  diff --git a/guix/scripts/substitute.scm 
>>>> b/guix/scripts/substitute.scm
>>>>  index 37cd08e289..3af0bf0019 100755
>>>>  --- a/guix/scripts/substitute.scm
>>>>  +++ b/guix/scripts/substitute.scm
>>>>  @@ -494,7 +494,9 @@ (define* (download-nar narinfo destination
>>>>      (define (try-fetch choices)
>>>>        (match choices
>>>>          (((uri compression file-size) rest ...)
>>>>  -       (guard (c ((and (pair? rest) (http-get-error? c))
>>>>  +       (guard (c ((and (pair? rest)
>>>>  +                       (or (http-get-error? c)
>>>>  +                           (network-error? c)))
>>>>                      (warning (G_ "download from '~a' failed, 
>>>> trying next URL~%")
>>>>                               (uri->string uri))
>>>>                      (try-fetch rest)))
>>>> 
>>>>  I’ll go ahead with this change if there are no objections.
>>>  Looks good to me! Thanks for looking into this :)
>> 
>>  OK, I’ll push it shortly, but…
>> 
>>  Lars Bilke <lars.bilke@ufz.de <mailto:lars.bilke@ufz.de>> skribis:
>> 
>>>  thanks Ada for bringing this issue up again. I get the same error 
>>> on
>>>  `guix pull` almost always when I am on my enterprise
>>>  network. Re-running `guix pull` a second time also almost always 
>>> then
>>>  runs fine. I checked with our IT: nothing suspicious on the 
>>> network,
>>>  i.e. no firewall blocking.
>>> 
>>>  I never experienced the error on my home network.
>> 
>>  … your reports make me think there’s a bug lurking somewhere 
>> that
>>  perhaps only manifests under some precise networking or timing
>>  conditions.
>> 
>>  Could the two of you run the following command in a loop to see 
>> whether
>>  it’s easy to reproduce that GnuTLS error?
>> 
>>    guile -c '(use-modules (guix http-client) (ice-9 binary-ports))
>>      (get-bytevector-all (http-fetch 
>> "<https://ci.guix.gnu.org/nix-cache-info>"))'
>> 
>>  If you can reproduce it, could you capture the strace output of the
>>  process?  You would run the command above prefixed by:
>> 
>>    strace -o log.strace -s 300 …
>> 
>>  Thanks in advance!
>> 
>>  Ludo’.
> 
Thanks,
Ada


[-- Attachment #2: Type: text/html, Size: 3359 bytes --]