bug-guix
[Top][All Lists]
Advanced

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

bug#45828: guix build: error: got unexpected path `Backtrace:' from subs


From: Ludovic Courtès
Subject: bug#45828: guix build: error: got unexpected path `Backtrace:' from substituter
Date: Wed, 13 Jan 2021 14:51:52 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

> There are errors in "/var/log/guix-publish.log" that could be the cause
> of this problem I think.
>
> GET /7m6mlzh0d6nifdxhaij7varg4q7lqdj4.narinfo
> In guix/scripts/publish.scm:
>     482:4  7 (render-narinfo/cached #<store-connection 256.99 7f916…> …)
>    487:12  6 (_ . _)
> In guix/store.scm:
>    1021:9  5 (_ #<store-connection 256.99 7f9165291230> "7m6mlzh0d6n…")
>     619:2  4 (write-buffered-output #<store-connection 256.99 7f9165…>)
> In unknown file:
>            3 (force-output #<output: string 7f91644a7690>)
> In guix/store.scm:
>     917:4  2 (write #vu8(29 0 0 0 0 0 0 0 32 0 0 0 0 0 0 0 55 109 …) …)
> In unknown file:
>            1 (put-bytevector #<input-output: socket 14> #vu8(29 0 …) …)
> In ice-9/boot-9.scm:
>   1669:16  0 (raise-exception _ #:continuable? _)
> In procedure fport_write: Broken pipe

As discussed on IRC today, the EPIPE above comes from talking to
guix-daemon, meaning that the store connection shown in the backtrace
has been closed by guix-daemon.

This can happen if guix-daemon was restarted but ‘guix publish’ wasn’t:
‘guix publish’ opens only one connection to the store at startup time,
and then never tries to re-open it.  There was an old bug on this topic:

  https://issues.guix.gnu.org/26705

Back then I marked it as ‘wontfix’ because:

  1. Losing a connection to the daemon Does Not Happen™ in normal
     conditions.  Namely, upon ‘herd restart guix-daemon’, ‘guix
     publish’ is automatically restarted.  One situation where ‘guix
     publish’ is not restarted is if one does “killall guix-daemon” or
     similar.  (Perhaps that’s something to fix in the Shepherd?)

  2. Catching EPIPE in the right place is tricky.  Basically we’d
     probably need to install a 'system-error handler around each RPC
     (and offer callers a way to choose the EPIPE handling strategy),
     which would incur additional overhead.

Ludo’.





reply via email to

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