Rongsong Shen
d26ff8870d
The buglog was one 27K-line JSON file whose fields covered only symptom,
root cause and fix, as free text: 2% of entries named the code version a
bug was found on, 12% the build profile, 36% a way to reproduce, and 58% of
the file was OpenWolf hook auto-detections ("Missing guard clause",
"Function not marked async" on .md files).
- .claude/skills/buglog/bug-record.md: the record standard. Eight
sections (Summary as the title, Description, Environment, Reproduction;
Root cause, Fix, Verification, References once fixed), each with the
content it must contain -- e.g. Environment needs the OS, the libc the
failing binary loads (from its ELF interpreter: glibc 2.42 in the nix
shell vs 2.40 on the host), toolchain, build profile and commit.
- .wolf/bugs/<id>.md: 500 records migrated from buglog.json; every field
verified to round-trip. They carry legacy: true and an explicit "not
recorded" where the old log had no such field; component derived from
file paths, severity from keywords (else unknown), fix_commits from
hashes in status_note/fix that git resolves (91 of 463 fixed).
- .wolf/buglog-archive.json: the 710 hook auto-detections, verbatim.
- .wolf/buglog.json is now an index generated from the records, keeping
the fields OpenWolf's hooks and `openwolf bug search` read.
- scripts/buglog.py rewritten: new (template + Environment collected from
the machine and --binary), check, status (refuses a status the record
doesn't support; fixed needs Root cause, Fix, Verification and
--commit hashes git resolves), note, recur, set, show, list, triage,
env, index. 29 unittest cases in scripts/tests/test_buglog.py.
- scripts/git-hooks/pre-commit runs `check --staged`: incomplete staged
records, a legacy record hand-changed to fixed without the fix-time
sections, a new record claiming legacy: true, or a stale index refuse
the commit.
- scripts/gitea-sync.py reads the records: issue body = the record's
sections plus linked fix commits (origin remote, GITEA_COMMIT_REPO to
override), and a body hash so an issue's text is refreshed when the
record changes.
- bug-1866 rewritten to the full standard as the worked example.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
3.8 KiB
| id | status | status_updated | status_note | component | severity | timestamp | last_seen | occurrences | files | tags | related | legacy | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| bug-1823 | fixed | 2026-09-24 | build | unknown | 2026-09-17T04:20:00Z | 2026-09-19T09:00:00Z | 1 |
|
|
|
true |
bug-1823: User-reported (regression on top of bug-1820's own fix, live on the user's real host, 'pc13v')…
Description
User-reported (regression on top of bug-1820's own fix, live on the user's real host, 'pc13v'): after ./scripts/stop-all.sh reported 'Stopping worker-1 (PID N)' with no warning, the real xcecd worker was STILL running afterward as a different PID -- and a second sudo ./scripts/stop-all.sh run immediately reported 'Nothing was running for this deploy' (the pidfile had already been deleted by the first run despite the kill not actually succeeding).
Environment
Not recorded (migrated from buglog.json).
Reproduction
Not recorded (migrated from buglog.json).
Root cause
bug-1820's own fix assumed sudo always has exactly ONE level of indirection (sudo forks exactly one direct child that IS the real target), and looked for that child via pgrep -P $PID (direct children of the pidfile'd PID only). On the user's real host, sudo interposes an ADDITIONAL 'monitor' process between the invoked sudo and the actual target (sudo -> monitor -> target, THREE processes, not two -- standard sudo 1.8.7+ architecture for proper signal/exit-status relay, not present in this sandbox's own simpler sudo build, which is why bug-1820's fix appeared to work here but not on the user's real box). pgrep -P $PID found and killed the MONITOR (a direct child of the pidfile'd PID) while the actual worker -- the monitor's OWN child, not a direct child of the pidfile'd PID -- survived completely untouched, silently orphaned exactly as in the original bug-1820 symptom. Confirmed and reproduced deterministically via a synthetic 3-level process tree (fake-outer -> fake-monitor -> fake-worker, no real sudo needed) built specifically to isolate the tree-walking logic from any particular sudo version's actual behavior.
Fix
FIXED (2026-09-17). Replaced the parent/child tree-walking approach entirely with a depth-independent identity-based re-scan: after attempting to kill the pidfile'd PID, both generated scripts/stop-all.sh and scripts/cleanup.sh now search system-wide (pgrep -f) for ANY still-running process whose own cmdline matches the worker's distinguishing identity -- its -n $NAME flag plus this specific deploy's -l $TOP/logs flag, the same two args start-worker.sh's own 'already running' guard already checks -- and kills every match directly (both a plain kill -9 and a sudo kill -9, since ownership can't be known in advance), regardless of how many hops deep in the process tree it landed. No longer needs to know or guess sudo's internal process-tree depth. A no-op for ctrl-N/scheduler/apiserver pidfiles, which use neither flag. Live-verified: (1) regression-checked against this sandbox's own real (2-level) sudo worker deploy -- still cleans up correctly; (2) built and killed a synthetic 3-level tree (fake-outer/fake-monitor/fake-worker, exact process-tree shape modeled on the user's live report) via the exact identity-pgrep mechanism the fix uses, confirming the deepest (target) process is found and killed directly, and the intermediate 'monitor' hop then exits on its own once its child is gone (it was just wait()-ing/relaying) -- proving the fix generalizes to arbitrary sudo process-tree depth rather than being tuned to one specific sudo version's behavior.
Verification
Not recorded (migrated from buglog.json).
References
- Related: bug-1820