build-watcher: guest-load liveness signal + wider silence tolerance - #174
Merged
Merged
Conversation
Container CPU alone misreads I/O-bound build phases: a cold Win64 compile start reads the engine tree through virtiofs, spending its time in D-state while the host-side VM process does the work — the cgroup shows ~0% CPU and UBT prints nothing until the first action completes, which reads exactly like the zombie deadlock. Two snappy prewarms were killed at 'Building 593 action(s) started' this way, each retry burning the ~40-minute patch+UHT prefix. D-state processes count into the guest load average, so probe /proc/loadavg from inside the container as a third required-idle signal (kernel-global = the VM's load, the right scope since one build owns the VM). Also raise DEFAULT_STALL_AFTER 300 -> 900: wine prefix init + the first SharedPCH batch legitimately exceeds five silent minutes. Probe failures still read as idle so a truly dead container remains reclaimable. Co-authored-by: Cursor <cursoragent@cursor.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
JPDuchesne
added a commit
that referenced
this pull request
Sep 16, 2026
Agent-isolation and emulated-Mac fixes: install-deps failure isolation with typed errors (#170), brew escalation to the prefix owner + AgentBootstrap sudoers edge (#171), BuildKit secret files in a verified per-uid dir under the data root — colima-visible and substitution-proof (#173), build-watcher guest-load liveness signal + 15m stall window (#174), sigpending ulimit for Rosetta signal-queue aborts (#175), and brew trust before tap in docker-install-build-deps (tap-rot fix).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Container CPU alone misreads I/O-bound build phases: a cold Win64 compile
start reads the engine tree through virtiofs, spending its time in D-state
while the host-side VM process does the work — the cgroup shows ~0% CPU and
UBT prints nothing until the first action completes, which reads exactly
like the zombie deadlock. Two snappy prewarms were killed at
'Building 593 action(s) started' this way, each retry burning the ~40-minute
patch+UHT prefix.
D-state processes count into the guest load average, so probe /proc/loadavg
from inside the container as a third required-idle signal (kernel-global =
the VM's load, the right scope since one build owns the VM). Also raise
DEFAULT_STALL_AFTER 300 -> 900: wine prefix init + the first SharedPCH batch
legitimately exceeds five silent minutes. Probe failures still read as idle
so a truly dead container remains reclaimable.
Co-authored-by: Cursor cursoragent@cursor.com