|Subject:||RE: Problems with "guix offload test" after re-install|
|Date:||Thu, 12 Oct 2017 10:02:49 +0000|
>> scheme@(guile-user)> (begin
>> (use-modules (guix))
>> (with-store store
>> (add-text-to-store store "test"
>> "Hello, build machine!")))
>> ERROR: In procedure display:
>> ERROR: In procedure display: Wrong type argument in position 2: #<closed: file c98f50>
>> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
>> scheme@(guile-user) >
> Could you try “,bt” here to show the stack trace? I wonder where that
> exception comes from.
Apologies that I didn’t include that before - the backtrace is shown below:
scheme@(guile-user) > ,bt
In current input:
12:25 3 (_)
864:9 2 (_ #<build-daemon 256.97 205be60> _ #vu8(72 101 108 # …) …)
618:13 1 (process-stderr _ _)
In unknown file:
0 (display "acquiring global GC lock `/var/guix/gc.lock'…" …)
scheme@(guile-user) > ,q
Connection closed by foreign host.
> Are you sure guix-daemon is running on this machine, and listening to
> the right socket file?
Yes, and this question along with the mention of “#<build-daemon” in the backtrace above was the clue I needed to find the source of the problem! I strace’d the guix-daemon, and comparing the successful and failing thread invocations (attached) I observed that the guix-daemon’s actions were identical right up until the point when it attempted to write to the calling guile instance (on file descriptor 4), and in the failing case was met with ECONNRESET at the end of what was otherwise a successful transaction. From this I guessed that the calling guile instance had closed the connection because it wasn’t able to grok the output being returned by the guix-daemon, and that made me remember that I had recently enabled the guix-daemon --debug flag. I then restarted the guix-daemon without the --debug flag, and “guix offload test” now works again!
I’m now back on track – many thanks for the pointer!
|[Prev in Thread]||Current Thread||[Next in Thread]|