-
Notifications
You must be signed in to change notification settings - Fork 340
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Devenv hangs forever #1364
Comments
It seems there's a problem with the latest versions of Nix. |
I've also managed to reproduce the issue in nix |
Could someone open an issue at https://github.com/NixOS/nix/issues |
Seems like they have fixed this, hopefully: NixOS/nix#11258 |
It's still hanging 🫠 |
`latest` makes "devenv" hang forever for some reason, see cachix/devenv#1364 for details, while more dated versions either lack essential features, including experimental ones, or works overall strangely.
Can confirm the same as above (w.r.t. versions) on a pretty vanilla Ubuntu 24.04. Some additional info:
As @rfhayashi mentioned (thanks!), downgrading Nix to 2.23.3 fixes everything. |
Looks like it might be resolved as of I had devenv hanging in Anyone else tried |
Can you extract the actual nix invocation that is hanging and/or attach gdb to that nix and pull a back trace of that instead? the one here is just saying it's waiting on output of some nix command but not what nix command or why it's stuck. |
Nix command:
GDB backtrace from
|
Produce the same backtrace in macOS:
|
Seems like the devenv patched Nix could not connect to the remote store anymore? Frame 6 Frame 5 |
Hmmm, yes this might be a protocol violation. I would be surprised if it were a bug in the devenv patched nix version because why on earth would you patch the protocol code? One inference I can draw here is it's likely a protocol desynchronization. I can't remember the protocol context in which the trusted flag is grabbed since my work on the protocol in lix, but it may be a protocol versioning fuck-up somehow. |
Funnily enough, I confirm that running as root, devenv still works perfectly fine. |
Running as root is expected to not get this problem because it's not using the nix protocol, it scribbles over the store without using the daemon. Ok so here's the part where you kind of cry: I would advise getting debug info from both the nix client and the nix daemon, then gdb both of them and run them in lock step. Nix protocol desyncs are a nightmare. |
Is this expected to reproduce on the devenv repo itself, or what is the flake being tested? |
Update: doesn't matter what the flake is, devenv-nix cannot connect to CppNix 2.24.3 at all. Reproducer:
In another window:
This will just get stuck in the same way as suggested above. Seems like a serious regression to me. If it's useful, it seems to desync before
I will also add, I am 90% sure we backported this bug into Lix and since fixed it, and it might be a since-fixed Nix 2.21 bug. |
|
OK I have figured out what the problem is: for some reason the nix-devenv Nix is reporting protocol 38, which it absolutely is not compliant with, which is then causing protocol negotiation to explode. Either this is a poorly thought out patch in devenv-nix, or a failure on the part of CppNix to increment protocol versions when they make protocol changes. I am going to go look at the devenv-nix patches and we are going to find out which one it is. Consider the client side:
And the server side:
|
This is a broken patch to devenv-nix: domenkozar/nix@537b7de is not safe to pick without the other protocol changes made prior to it, which seem to be missing as observed above (the client should be sending client features). |
cc @domenkozar Would you mind investigating this issue? I've noticed that even the latest Nix 2.23 (nor 2.24 I suspect) version does not support garbage collecting a closure, as reported in this issue. It might be safe to remove this feature temporarily. |
Going to look into this today/tomorrow. Thanks a lot @lf- |
Alternative solution strategies are
Due to how protocol versioning works, we can not provide guarantees about interoperability with non-released versions of Nix, including development branches like This may work better for future protocol versions since recently: However, that still doesn't mean that new operations don't change during development. |
Is there any workaround for us to get a working devenv while this is being fixed? |
The workaround is to downgrade Nix to 2.23.3 |
Silly me! I didn't even realise I could do that! # NixOS
nix = {
package = pkgs.nixVersions.nix_2_23;
} Just in-case anyone else wasn't aware either 👍🏻 |
Nix newbie here, this only works running NixOS? Otherwise, I have to re-run the installer and specify an older version somehow? |
Yeap, you have to uninstall (https://nix.dev/manual/nix/2.24/installation/uninstall) and install again using |
`latest` makes "devenv" hang forever for some reason, see cachix/devenv#1364 for details, while more dated versions either lack essential features, including experimental ones, or works overall strangely.
Determinate Systems has also released a new version of their installer with downgraded Nix. https://github.com/DeterminateSystems/nix-installer/releases/tag/v0.23.0 (Note: the older install can be removed using |
Can confirm it has been fixed. Thanks @domenkozar !! |
I'm on Arch and their latest Nix package as of today is causing this issue for me. I decided to install Lix instead and that works fine. |
Describe the bug
Hello!
I have a problem with Devenv on MacOS (Sonoma 14.6).
When I try to init devenv it hangs at the devenv init step:
It hangs forever if you don't press Ctrl-C.
I checked what it runs underneath the hood via ps and ran the same command with an extra verbose.
And it stuck on the evaluating file /.devenv.flake.nix.
The same thing happens if I'm trying to run any command.
For example if I run
devenv info
:And it hangs forever.
Same thing if I run the command manually:
I tried re-install nix and devenv but it didn't help.
To reproduce
devenv init
Examples are above.
Version
OS: MacOS Sonoma (14.6)
Nix version: 2.24.1
The text was updated successfully, but these errors were encountered: