Interrupted commands can crash in JSONLogger::write after nix::Interrupted

[schickling-assistant]

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:

1. Interrupting a long-running nix build.
2. Interrupting my own nix store gc --max 50G after 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

[schickling-assistant]

Additional local observation from the same mbp2025 setup:

• nix --version currently reports nix (Determinate Nix 3.17.0) 2.33.3, while determinate-nixd version reports daemon/client 3.18.1 and says the system is on the latest advised version. determinate-nixd upgrade refuses without root, so the local install may be in a partially upgraded state.
• Repeatedly interrupting/timing out a focused nix build left daemon-side work behind: root-owned nix-daemon __build-remote processes plus many _nixbld* bash -e ... source-stdenv.sh ... default-builder.sh processes stayed alive after the client exited.
• A global user-side timeout 90s nix build ... exits the client with error: 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

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

[cole-h]

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.