<rekado>the failing process has these _NIX_OPTIONS: <rekado>I’ll pass this to the separate “guix substitute” process and see what happens <civodul>i didn't want to distract you though :-) <rekado>I ran “guix substitute” with the exact same environment as the failing process; it does not fail <rekado>for the record, here’s the command: <rekado>SSL_CERT_FILE=/etc/pki/tls/certs/ca-bundle.crt PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin PWD=/ LANG=en_US.UTF-8 SHLVL=0 GUIX=/gnu/store/r8xb0r8vdvhyrjm61yih27gkxl2p8f6k-guix-command GUIX_STATE_DIRECTORY=/gnu/var/guix GUIX_CONFIGURATION_DIRECTORY=/etc/guix NIX_STORE_DIR=/gnu/store guix substitute --substitute <civodul>looks like _NIX_OPTIONS is being ignored <PurpleSym>rekado_: Thanks for taking a look, I’ll fix that. ***rekado_ is now known as rekado
<rekado>I wrote the nix options to a file (with proper newlines), and set them all with _NIX_OPTIONS=`cat nix-options` <rekado>I can see that they are in effect, because the output is now the usual daemon status strings (like “@ download-progress […]”) <rekado>I’ve set *all* of the environment variables and all of the _NIX_OPTIONS that are also in effect in the failing invocation. <rekado>an obvious difference now is deduplication <rekado>the standalone command does not have to deal with deduplication, so there are fewer syscalls <rekado>I should try artificially slowing down the network to simulate the delays caused by performing more work on NFS.