New here. I just tested
nix-build hello.nix and was then able to run
./result/bin/hello to test it.
What’s the recommended way of undoing this?
This is what I did:
# rm result
# nix-store --delete /nix/store/31icg8jxiyxkcmx8gwak3fvq9shi6fd8-hello-2.8
finding garbage collector roots...
removing stale link from '/nix/var/nix/gcroots/auto/8m1kkl216mxi8yn9pgn009838qil7mlv' to '/etc/nixos/result'
deleting unused links...
note: currently hard linking saves -0.00 MiB
1 store paths deleted, 0.18 MiB freed
Is that all I need to do?
result link, and then the left overs will be collected on the next
nix-collect-garbage --delete-older-than 14d which I do on a semi regular base at least once a week.
What @NobbZ said. Since nix creates a new build every time the inputs change there is no need to worry about cache invalidation. The only reason to clean the store is if you are running out of disk space.
The build result, which is a package (or whatever you call it) in the nix store, can only be deleted when it is not alive.
I noticed that deleting the
result symlink makes it not alive. Does this mean it detects if it is alive by detecting symlinks?
Based on bash - Linux: Find all symlinks of a given 'original' file? (reverse 'readlink') - Stack Overflow, it seems hard to detect what links point to a given file. Is it doing something else?
nix-build produces the
result symlink, it also places a symlink into
/nix/var/nix/gcroots/auto/ that points to the
result symlink. This serves as a GC root. When you run GC, it treats anything reachable from
/nix/var/nix/gcroots as live. These symlinks in
…/auto also get cleaned up during GC if what they point to doesn’t exist anymore.
For more information, check the documentation on
nix-store --add-root $path --indirect.
For more details on this behavior, see the manual or
When you run
nix-collect-garbage, you’ll see it cleanup all the “autoroots” that no longer exist as soon as it starts.