bug#26705: guix publish daemon on Hydra became dysfunctional; needed restart

["Ludovic Courtès" <ludo@gnu.org>]

ludo@gnu.org (Ludovic Courtès) skribis:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> While trying to update my GuixSD system in the last hour, I found that
>> every attempt by the substituter to download NARs resulted in a 500
>> "Internal Server Error":

[...]

>> GET /74ch6nvjfkj3i56nygwijnaghlpi01d4.narinfo
>> In guix/scripts/publish.scm:
>>     393:2  2 (render-narinfo/cached #<build-daemon 256.96 211f7c0> ...)
>> In guix/store.scm:
>>     663:9  1 (query-path-from-hash-part #<build-daemon 256.96 2...> #)
>> In unknown file:
>>            0 (put-bytevector #<input-output: socket 12> #vu8(# ...) ...)
>> ERROR: In procedure fport_write: Broken pipe
>> GET /guix/nar/qz4mg7sid6avdav158lhr6wziqswpjmx-gnome-calendar-3.22.2.tar.xz
>> In guix/scripts/publish.scm:
>>     491:8  2 (render-nar #<build-daemon 256.96 211f7c0> #<<requ...> ...)
>> In guix/store.scm:
>>     648:0  1 (valid-path? #<build-daemon 256.96 211f7c0> "/gnu/sto...")
>> In unknown file:
>>            0 (put-bytevector #<input-output: socket 12> #vu8(1 ...) ...)
>> ERROR: In procedure fport_write: Broken pipe
>
> Ooh, the connection to the daemon was broken, hence this error.
>
> Currently ‘guix publish’ assumes the connection opened in the
> ‘guix-publish’ procedure remains valid all along.  That’s normally the
> case unless (1) the daemon is restarted, or (2) there’s a protocol error
> somewhere that leads the daemon to close the connection.

For now I’m closing this bug as “wontfix” because I’ve never seen any
occurrence of #2, and because #1 cannot happen on GuixSD (if ‘guix-daemon’
is restarted, the shepherd will also restart ‘guix-publish’.)

Ludo’.