Repository navigation
Interrupted commands can crash in JSONLogger::write after nix::Interrupted #439
Description
Summary
On macOS with Determinate Nix 3.17.0, interrupting an active nix command can surface an internal crash path through the JSON logger instead of exiting cleanly after nix::Interrupted.
This was observed while debugging local Home Manager activation/build reliability. The activation hang itself turned out to be caused by local activation code and resource-pressure issues, but the interrupted Nix client crash appears separate and reproducible enough to report.
Environment
- OS: macOS Darwin, aarch64
- Nix:
nix (Determinate Nix 3.17.0) 2.33.3 - Binary:
/nix/var/nix/profiles/default/bin/nix
Observed behavior
Interrupting active commands produced crashes with stack frames like:
nix::Interrupted
nix::JSONLogger::write
nix::JSONLogger::logEI
nix::TeeLogger::logEI
nix::handleExceptions
I observed this in two separate situations:
- Interrupting a long-running
nix build. - Interrupting my own
nix store gc --max 50Gafter it had acquired the lock and started deleting.
For the GC case, the stack also included an interrupt-handling path around:
nix::ignoreExceptionExceptInterrupt
nix::JSONLogger::write
nix::JSONLogger::logEI
Expected behavior
An interrupted command should terminate cleanly with the normal interrupted/130-style behavior. Logging the interrupt/error should not itself crash or produce an internal exception path.
Why this matters
This makes local Nix operations harder to reason about during heavy rebuilds, GC, or activation debugging. It can look like the underlying build/GC path is corrupt when the actual extra failure is the client/logging path after interruption.
Notes
The local Home Manager issue I was investigating had separate root causes:
- unbounded activation-time secret reads waiting on interactive approval;
- activation verification that required runtime freshness instead of launchd convergence;
- local disk/resource pressure and broad rebuild invalidation.
Those were fixed locally. The remaining Determinate Nix concern is specifically the interrupted-command crash in/around JSONLogger::write.
Posted on behalf of @schickling
| field | value |
|---|---|
agent_name |
🧙 co2-sage |
agent_session_id |
d6fe14fc-126e-4968-a6b3-9bb4e8f4617b |
agent_tool |
Codex CLI |
agent_tool_version |
codex-cli 0.124.0 |
agent_runtime |
Codex CLI codex-cli 0.124.0 |
agent_model |
unknown |
worktree |
dotfiles/schickling/2026-04-26-misc |
machine |
mbp2025 |
tooling_profile |
dotfiles@1093d8c |
Activity
schickling-assistant commentedon Apr 29, 2026
Additional local observation from the same mbp2025 setup:
nix --versioncurrently reportsnix (Determinate Nix 3.17.0) 2.33.3, whiledeterminate-nixd versionreports daemon/client3.18.1and says the system is on the latest advised version.determinate-nixd upgraderefuses without root, so the local install may be in a partially upgraded state.nix buildleft daemon-side work behind: root-ownednix-daemon __build-remoteprocesses plus many_nixbld*bash -e ... source-stdenv.sh ... default-builder.shprocesses stayed alive after the client exited.timeout 90s nix build ...exits the client witherror: interrupted by the user, but the daemon-side build group can remain and later builds observe accumulated stale builders. I could not sample or restart those processes without sudo.In the repo-side experiment, the supposedly slow derivation phase was reproduced outside Nix in ~0.10s, while inside Nix the client hung and daemon-side builder processes survived interruption. That makes this look like a daemon/client interruption or build cancellation cleanup issue, not a package script bottleneck.
Posted on behalf of @schickling
agent_nameagent_session_idagent_toolagent_tool_versionagent_runtimeagent_modelworktreemachinetooling_profilecole-h commentedon Apr 29, 2026
You can try to force an upgrade to 3.18.1 with
sudo determinate-nixd upgrade --version v3.18.1.I believe this interrupt-crash issue was fixed after 3.17.0 (without a stack trace I can't be sure, but were two related fixes that were released in 3.17.1 and 3.17.2), but if you can reproduce on 3.18.1, I'd love to hear about that.