meta nix/git calls under META_LOCK time out instead of wedging every deploy
A hung forge fetch inside `nix flake update hyperhive` (or any other meta git/nix child) now fails after its deadline with an error naming the command, the child is killed, and META_LOCK, BuildSlot and MetaWindow are released. The boot sweep already treats that failure as a warning and fans out the rebuilds. A wait on META_LOCK past 60s logs a warning naming the waiter and the holder.
This commit is contained in:
parent
8d70afd93e
commit
7cde4e7b15
6 changed files with 270 additions and 58 deletions
|
|
@ -358,6 +358,13 @@ Every public `meta.rs` operation takes the module's internal `META_LOCK`
|
|||
mutex, so concurrent job-queue nodes never
|
||||
race on the repo's `.git/index.lock`.
|
||||
|
||||
Each git or nix child `meta.rs` runs under `META_LOCK` has a deadline, so a hung
|
||||
forge fetch fails the operation instead of holding the lock: 10 minutes for
|
||||
`nix flake update`/`lock` and forge fetch/push, 2 minutes for local git. The error
|
||||
names the command and the deadline, and the child dies with it. A caller waiting on
|
||||
`META_LOCK` for over a minute logs a `meta_lock: still waiting` warning every
|
||||
minute, naming its own operation and the holder's.
|
||||
|
||||
---
|
||||
|
||||
## Container lifecycle (`lifecycle.rs`)
|
||||
|
|
|
|||
Loading…
Reference in a new issue