This does not necessarily seem better than using --out-link to prevent the result from being garbage-collected. It seems pretty heavy to keep an entire process in memory (along with a nix-daemon worker process) just to keep track of a root.

With --out-link though you need to do cleanup. I've found result symlinks that weren't cleaned up when a script was interrupted to hard tons of times...

With nix keep-paths you have to clean up a process. Leaking a process is potentially much worse than leaking a symlink.

@edolstra You don't have to do anything to clean up the process. If your shell dies, it closes the fd and keep-paths gets a HUP.

(my test only closes the fd manually because I wanted to validate gc worked afterwards)

On the other hand, doesn't this solution require work on the daemon side while not fully eliminating the race condition? Maybe just nohup a process that (independently of Nix) waits for its stdin to get closed, then deletes a directory on tmpfs? In that case --link logic is supposed to guarantee that the symlink is created before GC has any chance to run.

@7c6f434c What race condition is there? Note that the daemon already supports process-lifetime temporary roots (this is how there's no chance of GC between evaluation and building in nix-build).

@7c6f434c If we're spawning a background process already, why not just have something that actually tracks roots with process lifetime, rather than hopefully having a chance to clean up a tempdir?

@shlevy You need to find outPath anyway, and outPath="$(nix-build --no-out-link something.nix)" is so convenient it will actually get used. Or nix build when it starts to print the outPath. You can evaluate outPath without instantiating, but that's enough of additional verbosity (and I think you cannot just build the resulting outPath without a re-evaluation) that nix keep-paths risks to be a feature that people use but usually incorrectly.

@7c6f434c Well if this gets merged the next step would be a Store implementation that punts indirect root creation off to keep-paths, then you can just do nix-build and it Just Works.

But, there's actually no risk even with your approach if you simply re-run nix-build after you register the root. Agreed it's verbose though.

I am not sure it will Just Work, as you have to specify the FD at some point as there is no safe FD number to assume (if we include scripts running under ulimit). But yes, it will be nice.

What is a rough outline of the needed flags/open FDs/communication with daemon?

Double-build is one of the multiple available ways that are verbose enough to incentivise Using It Wrong.

(obviously the keep-paths:// protocol doesn't exist yet)

And some quoting is also needed.

Frankly, that looks scary enough to wrap, and if I wrap it anyway, I can wrap using a solution that works now: nix-build with a link into a temprorary directory, open the output or change directory there, wait for parent to die.

Still it would be nice to be able to keep store paths in a race free way alive without using the filesystem (e.g. for nixos-rebuild). Temporary directories are quite hard to use without introducing new races.

Maybe something like a "file descriptor api" for nix would be handy? Something like this:

Allow passing a file descriptor from the parent process, which is used as a communication channel. The nix process communicates when the build is done and outputs the build result over the fd, and then waits for the caller to communicate, that the gc lock on store path can be lifted, before exiting.