bug#55441: [cuirass] hang in "In progress..."; runs out of pgsql connections

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

Hi,

Ludovic Courtès <ludo@gnu.org> skribis:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Berlin was reconfigured with this commit of Cuirass, and is now running
>> the derivations with it, but so far still "In progress..." after more
>> than 100 minutes [0]
>
> Yeah, I’m not sure about the backtrace you report, however there’s again
> a bunch of ‘cuirass evaluate’ processes hanging, this time with the main
> thread stuck on ‘waitpid’ (presumably from the ‘close-inferior’ call):

An update: I ran this by hand:

--8<---------------cut here---------------start------------->8---
$ sudo su - cuirass -s /bin/sh -c "/gnu/store/z8haznhwck4bjm4gxqy25wvwv4041wvx-cuirass-1.1.0-12.f087aaf/bin/cuirass evaluate dbname=cuirass 326988"
Computing Guix derivation for 'x86_64-linux'... -^-
warning: call to primitive-fork while multiple threads are running;
         further behavior unspecified.  See "Processes" in the
         manual, for more information.
warning: call to primitive-fork while multiple threads are running;
         further behavior unspecified.  See "Processes" in the
         manual, for more information.
warning: call to primitive-fork while multiple threads are running;
         furthwarning: call to primitive-fork while multiple threads are running;
         further behavior unspecified.  See "Processes" in the
         manual, for more information.
warning: call to primitive-fork while multiple threads are running;
         further behavior unspecified.  See "Processes" in the
         manual, for more information.
warning: call to primitive-fork while multiple threads are running;
         further behavior unspecified.  See "Processes" in the
         manual, for more information.
--8<---------------cut here---------------end--------------->8---

… and attached ‘strace’, which shows things are working as intended:

--8<---------------cut here---------------start------------->8---
read(228, "r6x878i3fyr12lf9v496cl9x5jh6-gzip-1.10.drv\" \"/gnu/store/6280r7vqfp5qkv6cdib02203xw1sk7h3-binutils-cr"..., 4096) = 4096
read(228, "pper-0.drv\" \"/gnu/store/45wsr6x878i3fyr12lf9v496cl9x5jh6-gzip-1.10.drv\" \"/gnu/store/6280r7vqfp5qkv6c"..., 4096) = 4096
read(228, "8qy2pnpn2030xxfmm56h71-gettext-0.21-doc\") (\"out\" . \"/gnu/store/gmrqdvy9v42hfbs6b7vaxfrwf8b5qhqy-gett"..., 4096) = 4096
read(228, "\" \"/gnu/store/k5889v7ms3f5x1rjr3php71k4743fn19-bash-minimal-5.1.8.drv\" \"/gnu/store/lbyw1h3xz33qnb08j"..., 4096) = 4096
read(228, "x2g7ysm16xqnrpbkqdc4hhni1r42dgg-patch-2.7.6.drv\" \"/gnu/store/3fy0f7gy85ddy6rpa4mmhjygns8qzk03-findut"..., 4096) = 4096
read(228, "08s1nz9bpv6k6a56idv6l7r2zjqphszl-file-5.39.drv\" \"/gnu/store/1x2g7ysm16xqnrpbkqdc4hhni1r42dgg-patch-2"..., 4096) = 4096
read(228, "tore/azdhavgwpjc527n81iqwrf91v8sv3x23-help2man-1.48.5.drv\" \"/gnu/store/b1pi5ssin56s4mqq6964hsh2bdkyd"..., 4096) = 4096
read(228, ") (#:nix-name . \"guix-1.3.0-25.c1719a0\") (#:system . \"x86_64-linux\") (#:max-silent-time . 3600) (#:t"..., 4096) = 121
close(228)                              = 0
wait4(83882,    # hangs forever
--8<---------------cut here---------------end--------------->8---

The question to me becomes: why is ‘guix repl’ not getting EOF from its
read(0, …) call?

FWIW, here’s an estimate of the amount of data transferred from the
inferior to the main process:

--8<---------------cut here---------------start------------->8---
$ grep 'read(228, .* = 4096$' <log.evaluate|wc -l
25807
--8<---------------cut here---------------end--------------->8---

I’m trying to reproduce that synthetically.

Ludo’.