bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#48903: guix substitute: error: TLS error in procedure 'read_from_ses


From: Maxim Cournoyer
Subject: bug#48903: guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet.
Date: Tue, 29 Jun 2021 09:23:18 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hello Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

[...]

> As a first step, can you reproduce the bug like this:
>
>   while echo substitute
> /gnu/store/44h13hn5zssfppz67vydxcf95qsc8qfw-libreoffice-6.4.7.2 /tmp/t
> | guix substitute --substitute ; do chmod -R +w /tmp/t && rm -rf
> /tmp/t; done
>
> ?
>
> FWIW, I can’t seem to reproduce it with:
>
> $ guix describe 
> Generacio 185   Jun 07 2021 15:07:46    (nuna)
>   guix e3611cc
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: e3611cc412e7b1c750a56d17fb1b7cde684baa3f

I can't seem to reproduce either.  Perhaps the issue only arises when
there are many things happening concurrently.  My daemon runs with:

--8<---------------cut here---------------start------------->8---
$ sudo ps -eF | grep guix-daemon
root     25193   216  0  3074  1524   3 Jun28 ?        00:00:00 
/gnu/store/vphx2839xv0qj9xwcwrb95592lzrrnx7-guix-1.3.0-3.50dfbbf/bin/guix-daemon
 25178               guixbuild --max-silent-time 0 --timeout 0 
--log-compression none --discover=no --substitute-urls http://127.0.0.1:8080 
https://ci.guix.gnu.org --max-jobs=4--8<---------------cut 
here---------------end--------------->8---

I can rather easily (and annoyingly!) trigger the problem (and a few
variations of it, it seems) with something like:

$ packages=$(guix refresh -l protobuf | sed 's/^.*: //')
$ guix build -v3 --keep-going $packages

For example, running the above, I just got:

--8<---------------cut here---------------start------------->8---
guix build: error: corrupt input while restoring archive from #<closed:
file 7fc95acfc2a0>
--8<---------------cut here---------------end--------------->8---

Does the above commands succeed on the first time on your end?  If you
have already lots of things cached, you can try for an architecture you
don't often build for by adding the '--system=i686-linux' option; that
should cause a massive amount of downloads, likely to trigger the
problem.  Perhaps also try to use --max-jobs=4.

If you have ideas of how to debug this when I hit the issue I'm all ears
:-).

Thank you!

Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]