Hi, Mathieu Othacehe 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 # …) > 487:12 6 (_ . _) > In guix/store.scm: > 1021:9 5 (_ # "7m6mlzh0d6n…") > 619:2 4 (write-buffered-output #) > In unknown file: > 3 (force-output #) > 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 # #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’.