[Top][All Lists]

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

Re: Problems with "guix offload test" after re-install

From: Ludovic Courtès
Subject: Re: Problems with "guix offload test" after re-install
Date: Fri, 13 Oct 2017 17:41:26 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)


"Brantley, Michael" <address@hidden> skribis:

> ...
>>> 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) [1]>
>> 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) [1]> ,bt
> In current input:
>     12:25  3 (_)
> In guix/store.scm:
>     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) [1]> ,q
> scheme@(guile-user)> ,q
> Connection closed by foreign host.

So guix-daemon on this machine is running with --debug or similar (hence
the “acquiring global GC lock” message), and when it tries to write its
error messages to (current-build-output-port) aka. (current-error-port),
it turns out that this port is closed.

I’m not sure why (current-error-port) is closed.

Does it help to terminate the “guile --listen” process?

>> 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!

Oh OK, so it does have something to do with --debug.


reply via email to

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