Allow to Ctrl-C the program

[soenkehahn]

Currently it seems that it the program does not respond do SIGINT or SIGTERM. It'd be nice if I could Ctrl-C it.

[risicle]

During what phase are you having trouble getting it to respond? During the phases where control is passed to libnixstore it's potentially very tricky to do this. FWIW it does tend to respond, but only once control has returned to python.

How does nix-collect-garbage behave when you give it ctrl-c during the same phase?

[soenkehahn]

For example after nix-heuristic-gc prints determining live/dead paths... I cannot ctrl-c it. Ah, I see now that it just takes a really long time to terminate. (I guess then this ticket is about ctrl-c just taking very long.)

nix store gc -v fairly quickly starts deleting store paths and then it responds to ctrl-c very quickly.

[risicle]

Hmm.. the determining live/dead paths bit is the same code as nix itself uses, so there shouldn't be any performance difference between the two, though if you run the nix command after everything's warmed up in cache it will probably (seem to) run much faster.

[soenkehahn]

For me nix-heuristic-gc hangs (i.e. doesn't ouput anything) a bit after printing determining live/dead paths. It hangs for about 30 seconds, during which it doesn't immediately respond to ctrl-c. That happens even when I try to warm any caches with nix store gc -v (or nix-heuristic-gc itself). nix store gc seems to never be in a phase that lasts that long where it doesn't respond to ctrl-c.

[risicle]

Yeah so I think you'll find that the phase following determining live/dead paths has two phases - a first phase which is the same as that done by nix store gc (although unlike nix store gc doesn't respond to ctrl-c - I'll get to that) and then a later phase where it's building up a bunch of StorePath objects, hashing strings and jumping in and out of python code and this will respond to ctrl-c. This latter phase is what makes it seem to take longer than nix store gc.

During the early phase we appear to ignore ctrl-c because python installs its own handler for SIGINT that simply sets a flag that the python interpreter will periodically check for. But when we're in non-python code, that ain't gonna happen. I could probably do something to un-install the python signal handler during the long call, but the tricky bit would be figuring out how to exit the process gracefully while you have uncooperative code running. Technically I could just abort the process abruptly, but that's what SIGKILL is for. Might have to take a closer look at what the nix code itself is doing in such a case.

[soenkehahn]

Yeah so I think you'll find that the phase following determining live/dead paths has two phases - a first phase which is the same as that done by nix store gc (although unlike nix store gc doesn't respond to ctrl-c - I'll get to that) and then a later phase where it's building up a bunch of StorePath objects, hashing strings and jumping in and out of python code and this will respond to ctrl-c. This latter phase is what makes it seem to take longer than nix store gc.

During the early phase we appear to ignore ctrl-c because python installs its own handler for SIGINT that simply sets a flag that the python interpreter will periodically check for. But when we're in non-python code, that ain't gonna happen. I could probably do something to un-install the python signal handler during the long call, but the tricky bit would be figuring out how to exit the process gracefully while you have uncooperative code running. Technically I could just abort the process abruptly, but that's what SIGKILL is for. Might have to take a closer look at what the nix code itself is doing in such a case.

I'm not sure about what's going on under the hood. But to describe what I'm observing with bit more detail:

• I ran nix build .
• I'm starting time ./result/bin/nix-heuristic-gc 10K.
• It almost instantly prints

2026-02-04 09:55:07,937:INFO:nix_heuristic_gc.graph: querying dead paths
finding garbage collector roots...
determining live/dead paths...

• I type ctrl-c
• I wait until it prints

Traceback (most recent call last):
  File "/nix/store/id3s7c3lqzzp18ykzl5pjqxja97vi1hy-python3.12-nix-heuristic-gc-0.7.2/bin/.nix-heuristic-gc-wrapped", line 9, in <module>
    sys.exit(main())
             ^^^^^^
  File "/nix/store/id3s7c3lqzzp18ykzl5pjqxja97vi1hy-python3.12-nix-heuristic-gc-0.7.2/lib/python3.12/site-packages/nix_heuristic_gc/__main__.py", line 219, in main
    nix_heuristic_gc(**parsed)
  File "/nix/store/id3s7c3lqzzp18ykzl5pjqxja97vi1hy-python3.12-nix-heuristic-gc-0.7.2/lib/python3.12/site-packages/nix_heuristic_gc/__init__.py", line 53, in nix_heuristic_gc
    garbage_graph = GarbageGraph(
                    ^^^^^^^^^^^^^
  File "/nix/store/id3s7c3lqzzp18ykzl5pjqxja97vi1hy-python3.12-nix-heuristic-gc-0.7.2/lib/python3.12/site-packages/nix_heuristic_gc/graph.py", line 205, in __init__
    garbage_path_set, _ = self.store.collect_garbage(
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: error: interrupted by the user
./result/bin/nix-heuristic-gc 10K  0.09s user 0.02s system 0% cpu 1:51.12 total

As you can see in the last line it takes almost two minutes until it reacts to the ctrl-c. (Yesterday with the same measurement I came out at 30 seconds for some reason.)

I never seem to be able to get nix store gc to take longer than say a second to respond to ctrl-c.

(Sorry this is such a vague bug report. Overall this tool is great, thanks for working on it!)

[risicle]

Yeah I think I know how I can address this in a graceful way, but I'll need to experiment a bit with signal handlers.

[risicle]

How does #15 work for you?

[soenkehahn]

Works great, left a review at #15.