Crash during nixos-rebuild #542
Labels
No labels
Area/build-packaging
Area/cli
Area/evaluator
Area/fetching
Area/flakes
Area/language
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/store
bug
crash 💥
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
RFD
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
ux
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#542
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Describe the bug
Steps To Reproduce
nixos-rebuild boot --target-host 192.168.0.27 --use-remote-sudo --flake .#worky
as a normal non-root userI'm not actually sure how reproducible this is, I only tried/saw this once.
Expected behavior
Lix shouldn't crash. However, the error about lacking a trusted signature is correct, I accidentally did
--target-host 192.168.0.27
instead of--target-host root@192.168.0.27
.nix --version
outputnix (Lix, like Nix) 2.92.0-dev-pre20241005-ed9b7f4
Additional context
#229 can probably be closed now :P
oh this is a bug but it's not the bug you'd think. i think nix::Interrupted gets caught in the new error printing machinery in spite of not being a bug in lix.
the broken pipe error is semi expected in that we know the daemon hangs up with certain errors (but possibly a regression that it's printed, will have to contemplate a bit).
oh. the Interrupted exception fell out of the end of the thread, as i observe when actually reading the stack trace; gods i am so glad i wrote that thing. that's 100% the thread pool code's fault and is 100% a bug. cc @rbt.
either we have a bad cherry pick or the cherry picked code completely overlooked that exceptions could fall out of the thread and didn't make it a clean thread termination. either way, goofy, this is a lix bug. the thread pool should eat terminated exceptions and cleanly stop the thread.
(the cool part about this infrastructure is that it telling you it's a lix bug is tautologically true! either it's a lix bug that it's telling you it's a lix bug, or it's a lix bug!)
This issue was mentioned on Gerrit on the following CLs: