-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Various Nix commands ignore Ctrl-C (SIGTERM) #7245
Comments
I think #6995 might help, but I have seen this happen even with that change. |
Can the Nix project at least cut a release with #6995 included? There have been 220 commits since the last release:
|
I don't think this is isolated to a mac. My most annoying experience with this is when using |
Does it happen outside of direnv though? I tried pretty hard to repro it on Linux in the past and could never get it to happen. Could be it's just much rarer though. It could also be a bug in direnv. |
I don't see how it could be direnv when I have to send a IIRC, this has also happened to be a few times during a heavy |
Yeah that sounds like nix :). It is really hard to repro. I was getting it to happen like 1 out of 10 times or something. I believe it happens the most during download threads. |
I've seen this happening a few times indeed. It might a duplicate of #5438. I can't manage to reproduce it reliably (the reproducer in the issue doesn't work for me, I only get a few seconds of delay between my C-C and Nix stopping)<. However, I suspect it's either linked to the download threads as @matthewbauer suggests or the serialization that happens when copying the files to the store. |
I'm on a 20-core machine which may exacerbate the issue. |
If this is helpful to anyone I'm almost certain the issue is specifically hitting There might be a valid reason for this, but in practice it means I usually have to I hadn't restarted my box for about a week and found ~30 hung I can reproduce the issue reliably in most large repos with a dirty tree, or by fetching a large number of tarballs with If you want a test subject with a gross number of tarballs ( ~500 ) you can try
You can |
Not stale. Is there any way we can get this issue prioritised? I've been in a place with poor network conditions for the past week, and the amount of hours waiting for nix to exit because it does not respond to interrupt signals is extremely frustrating to the point that it's basically unusable. |
It's annoying if Ctrl-C doesn't work, but you can just kill it. No need to wait for hours. |
Yes but it's not good UX. E.g. these lockups also happen when you autocomplete a nix flake. So it's not even clear to the user a nix process is running |
Overheard on matrix:
Adding new-cli label. |
It also happens in the old-cli commands for sure though. Run into this at work every day and we're still using the old nix cli. I think for the old CLI the trigger is |
I have also noticed this and had to go and kill these processes. Additionally, when I've done so, it's left some things in a locked state that's difficult/slow to restart. So it's a significant UX issue |
Yeah this one is annoying. |
I'm seeing this when a nix operation triggers a garbage collect |
Since 2.17 I also experience this whilst nix is doing evaluation and no fetching e.g. |
Anyone who is investigating this: @aakropotkin's command can be used to reliably reproduce this issue. Here is an updated command using the revision when he posted the comment:
|
This is a backtrace I was able to obtain:
|
I'm able to consistently trigger this after the following output occurs
|
Likely related to fetchTree clean up when interrupted. If we fix it in that one spot, it might resolve much of this. Is there a handler similar to https://github.com/NixOS/nix/blob/master/src/libstore/filetransfer.cc#L560 in the fetchTree codepath? |
I can attest to this. Nix prints this just before starting to evaluate the downloaded |
Otherwise Nix deadlocks when Ctrl-C is received in withFramedSink(): the parent thread will wait forever for the stderr thread to shut down. Fixes the hang reported in NixOS#7245 (comment).
#9687 should fix the hang reported by @aakropotkin. |
Otherwise Nix deadlocks when Ctrl-C is received in withFramedSink(): the parent thread will wait forever for the stderr thread to shut down. Fixes the hang reported in #7245 (comment). (cherry picked from commit 24e7048)
Nevermind, I'm reopening this:
|
Describe the bug
Several Nix commands seem to ignore
Ctrl-C
for lengthy periods. I'm not sure exactly what conditions cause this, but I've seen it withnix flake update
,nix develop
, andnix-shell
.Steps To Reproduce
With this
flake.nix
:Run
nix flake update
, and wait until thedownloading 'https://api.github.com/repos/NixOS/nixpkgs/tarball/...
message disappears. PressingCtrl-C
at that time will be ignored.On subsequent runs, no message will be printed to stdout before
nix flake update
starts ignoringCtrl-C
. UPDATE: It looks like on subsequent runs,nix flake update
deadlocks entirely afterCtrl-C
is pressed. I've been watching this do nothing for 10 minutes (far longer than it should take to get the commit hash ofmaster
on thenixpkgs
repo):Expected behavior
The program exits cleanly and immediately.
nix-env --version
output:Additional context
Observed on M1 macOS (
aarch64-darwin
).The text was updated successfully, but these errors were encountered: