That sounds like virtual memory which does not really matter. Most haskell programs have that set to 1TB.
The OOM killer got it eventually, but in mainline operation it fluctuated between 11GiB and 40GiB of real memory.
I’m getting an odd error, “incorrect output”:
$ nix store make-content-addressed --all
error: derivation '/nix/store/hi3j7zj1ig2x1qnva8csxmq4ry88gzym-hscolour-1.24.4.drv' has incorrect output '/nix/store/fmas9wlcibxc59c7dq7z6rhxjz57gfdg-hscolour-1.24.4-data', should be '/nix/store/v87cgbhgbxsmw2dzs0a3ysgd8hbcp4qd-hscolour-1.24.4-data'
nix store verify --all
is happy though?
Also,
$ nix --version
nix (Nix) 2.11.0
$ nix show-derivation /nix/store/hi3j7zj1ig2x1qnva8csxmq4ry88gzym-hscolour-1.24.4.drv
error: path '/nix/store/hi3j7zj1ig2x1qnva8csxmq4ry88gzym-hscolour-1.24.4.drv' is not a valid store path
but the file exists, so presumably the store didn’t add it to the db?
I am having the exact same problem:
nix store make-content-addressed --all
error: derivation '/nix/store/7z63ndpzk3rvp3hhqp5mb15g7yn75mga-linux-headers-static-5.19.drv' has incorrect output '/nix/store/cz934gbnggvh1hi3gcfqw8gppgh38hrm-linux-headers-static-5.19', should be '/nix/store/viwsyykm4lninzhpi43gc7dv9d656ql4-linux-headers-static-5.19'
> nix show-derivation /nix/store/7z63ndpzk3rvp3hhqp5mb15g7yn75mga-linux-headers-static-5.19.drv
error: path '/nix/store/7z63ndpzk3rvp3hhqp5mb15g7yn75mga-linux-headers-static-5.19.drv' is not a valid store path
> exa -l /nix/store/7z63ndpzk3rvp3hhqp5mb15g7yn75mga-linux-headers-static-5.19.drv
.r--r--r-- 3,0k root 1 Jan 1970 /nix/store/7z63ndpzk3rvp3hhqp5mb15g7yn75mga-linux-headers-static-5.19.drv
I have tested config.contentAddressedByDefault = true;
in my flake based setup on three x86_64 machines last week and reverted again today. My experience was mixed:
- It actually worked! (yay)
- It took a long time to basically (re)build every package in my config. Stuff like
gfortran
libreoffice
etc. do take their time. - My deployment tools (
deploy-rs
) did not work with CA derivations due to the path being unknown during evaluation. I hacked together a fix to make it deploy (still WIP!, see Incompatibility with content-addressed derivations · Issue #164 · serokell/deploy-rs · GitHub) - I was hit repeatedly by build failures due to (probably unrelated) Nix bugs like Remote Building Experienence massively degraded since ~2-3 months or nix-build: requires non-existent output 'out' from input derivation · Issue #6572 · NixOS/nix · GitHub which slowed the rebuild
- No
nix-serve
implementation I have tried was able to provide therealisations
endpoint to make a binary-cache useful (I have looked atnix-serve
,nix-serve-ng
andharmonia
). I took a look at ca-derivations support by thufschmitt · Pull Request #21 · edolstra/nix-serve · GitHub, fixed the stale nixpkgs override (see GitHub - gador/nix-serve at pr-21) and managed to getnix-serve
running with therealisations
endpoint. This, however, didn’t really help because I either got hit by Content-addressed realisations can't always be registered · Issue #5220 · NixOS/nix · GitHub (due to different local and remote versions of the same package) ornix build
still tried to rebuild everything, although the.drv
file, andout
path are available on the binary-cache. Of course I also tried withssh-ng
store, butnix build
still tried to rebuild everything. I suspect this is because the localnix
didn’t connect the derivation with the realisation of theout
path. (I also tried copying theout
path to the local machine, but this resulted in the error messages with conflicting versions of the same package. No garbage-collecting helped there either)
So all in all I was really happy to see it worked, but in its current form I cannot use it in production.
I get the following error with config.contentAddressedByDefault = true;
error: opening file '/nix/store/naf68a3znxdc8zpwba1prwiyjqz7z09v-bash-5.1-p16.drv': Too many open files
corrupted double-linked list
this went away after a few nixos-rebuilds. Now I am crashing with
error: derivation '/nix/store/zpc7fx6jkycw57jnigvi7b7dgyckcdnl-flac-1.4.1.drv' doesn't have expected output 'bin' (derivation-goal.cc/resolvedFinished,realisation)
I had this hundreds of times. Just retry the build and it should hang at the next output not found
now I am failing with
error: creating pipe: Too many open files
corrupted double-linked list
I finally managed to build everything. But after rebooting my system hangs when loading initrd. Screenshot attached.
I’m just getting (repeatedly):
error: creating pipe: Too many open files
corrupted double-linked list
building the system configuration...
Fails in just a couple seconds and doesn’t seem to make any progress.
EDIT:
$ ulimit -n
1024
In my tests I had this same error, I think is related to libcurl multiplexer to cache.nixos, at least, is what last messages using -vvv shows.
Tested with nix 1.15.0
Maybe it will be fixed in the next version since --max-substituter-jobs · Issue #3379 · NixOS/nix · GitHub is closed by `max-substitution-jobs` setting by urbas · Pull Request #8299 · NixOS/nix · GitHub
My lsof -u root nixos rebuild files · GitHub show a lot of FIFO
https://github.com/NixOS/nix/pull/4282 got merged
Wondering if it is related to creating pipe: Too many open files
What is the status of CA derivations? @thufschmitt are you still working on this? Is there a roadmap for the experimental feature?
That’s unfortunately blocked on the Hydra side of things. Allow building content-addressed derivations with hydra - reprise by aciceri · Pull Request #1228 · NixOS/hydra · GitHub is the latest attempt, but stalled because no one is able to properly review it.
We really need to get this done. If I am given commit bit, I will review it and Split the `buildRemote` function by thufschmitt · Pull Request #1180 · NixOS/hydra · GitHub myself; I did not write either of those so while I am obviously for the ideas I am still an independent reviewer.
Update, I did get commit bit and Split the `buildRemote` function by thufschmitt · Pull Request #1180 · NixOS/hydra · GitHub was merged!
I have made Add support for CA derivations · Issue #838 · NixOS/hydra · GitHub a tracking issue for this. The next development step is code review for Prepare for CA derivation support with lower impact changes by Ericson2314 · Pull Request #1316 · NixOS/hydra · GitHub. I encourage anyone who is curious to give it a look over; the more eyes the better!
Concurrently, on the ops side, it would be good to update hydra.nixos.org to the latest master
(prior to merging that PR), which includes a Nix 2.17 → 2.19 bump. Per the tracking issue I don’t want the prod deployment to jump too many commits at time, as that makes unexpected issues (a) more likely and (b) harder to debug if they do occur.
Hoping we can finally get Nixpkgs CA derivations enabled CI’d and cached in 2024!
Very hyped for this :3