`nix develop --command nix build` fails for some derivations in `nixos/nix` docker image
I have the most minimal reproduction I could come up with here using nixos/nix:2.15.0.
Basically, the bug is that running nix develop --command nix build breaks, but only in the docker image. On my actual machine, this works fine. Additionally, running nix build without nix develop --command works fine both on my actual machine and in the container. This is all explained/demonstrated in the linked repository.
It's unknown to me whether this is reproducible with non-flakes equivalents, I didn't try.
I've also just noticed that changing packages.${system}.default to:
packages.${system}.default = derivation {
inherit system;
name = "wat";
builder = "/bin/sh";
args = ["-c" "echo wat > $out"];
};
does not reproduce the issue.
However, given that this behavior only arises depending on where (i.e. in or out of a docker container) nix is being invoked, I think this issue belongs here rather than nixpkgs.
Priorities
Add :+1: to issues you find important.
the bug is that running
nix develop --command nix buildbreaks
How? What breaks? Do you have logs?
Yes, they're in the readme of the repo linked in the first sentence. I'll reproduce the logs for the incorrect behavior here:
error: builder for '/nix/store/iw1qf7h7jjxpkjf7759vv4pmr5hwswza-wat.drv' failed with exit code 1;
last 2 log lines:
> unpacking sources
> variable $src or $srcs should point to the source
For full logs, run 'nix log /nix/store/iw1qf7h7jjxpkjf7759vv4pmr5hwswza-wat.drv'.
I'll inline the flake.nix here while I'm at it I guess:
{
inputs = {
nixpkgs.url = "github:NixOS/nixpkgs?ref=nixos-unstable";
};
outputs = {
self,
nixpkgs,
}:
let
system = "x86_64-linux";
pkgs = nixpkgs.legacyPackages.${system};
in
{
packages.${system}.default = pkgs.runCommandLocal "wat" {} ''
touch $out
echo wat > $out
'';
devShells.${system}.default = pkgs.mkShell {};
};
}
Something about the docker container seems to break how passAsFile handles $TMPDIR. The example works with this patch
--- a/flake.nix
+++ b/flake.nix
@@ -17,6 +17,8 @@
echo wat > $out
'';
- devShells.${system}.default = pkgs.mkShell {};
+ devShells.${system}.default = pkgs.mkShell {
+ shellHook = "unset TMPDIR";
+ };
};
}
Huh, yeah, I can confirm that makes it work in all cases. Very strange.
I have the same issue : it works on my machine but fails in the CI or on my machine inside a container
https://gitlab.com/pinage404/nix-sandboxes/-/jobs/4634026045#L1000
even adding shellHook = "unset TMPDIR"; doesn't fix the problem
https://gitlab.com/pinage404/nix-sandboxes/-/jobs/4663181133#L1007
Probably related
https://github.com/NixOS/nix/issues/6778
https://github.com/NixOS/nix/issues/7154
Just dropping by to say this problem persists in 2.19.2 (hence the title change).
Issue is still in latest. Unsetting TMPDIR helps.
Still an issue in nix 2.23.1. In an alpine image with installed nix.
I get this error too: I do in an alpine container (root) after entering the devShell with nix develop I have exactly two tmp directories
-
/tmp/nix-develop-17934-1835: which seems fromnix develop??? It has permissions:drwxr-xr-x 1 root root. -
/tmp/nix-shell.1es4eb: Seems to be the tmp dir from thedevShell.defaultin theflake.nix... It seems to have weird permissions:drwx------ 1 root root. -
TMPDIRis set to/tmp/nix-shell.1es4eb.
Then the following can be observed with nix build --rebuild:
-
If I unset
TMPDIRin the shell it works. -
If I set
TMPDIR=/tmpit works. -
If I set
TMPDIR=/nix-develop...(see above) , **the rebuild is non-deterministic.**because the derivations do not match. (which is weird) -
If I set
TMPDIR=/nix-shell...(see above), the rebuild crashes withmktemp: failed to create file via template '/tmp/nix-shell.8h3Yn3/nix-build-rdf-protect.drv-0/tmp.XXXXXXXXXX': Permission denied -
If I set
TMPDIR=/nix-shell...(see above) and correct the permissions todrwxr-x-r-xthe build works but is non-deterministic. -
If I set
TMPDIR=/tmp/gagaandmkdir -p gaga-> the build works but is non deterministic
This might look to me as a newbie the different TMPDIRs are used during build or something like that, which is weird...
But might be wrong...