Hi, Ludovic Courtès <[email protected]> skribis:
> Hi, > > Maxim Cournoyer <[email protected]> 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’.
