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>
6.2 KiB
| id | status | status_updated | status_note | component | severity | timestamp | last_seen | occurrences | files | tags | related | legacy | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| bug-1586 | wontfix | 2026-09-24 | not a bug: resval getters mode-agnostic, live values confirmed non-zero | worker | security | 2026-08-19T02:47:00Z | 2026-09-19T09:00:00Z | 2 |
|
|
|
true |
bug-1586: User-reported, same live REPL session: info worker all shows total=0.00 available=0.00 for…
Description
User-reported, same live REPL session: info worker all shows total=0.00 available=0.00 for mem/r1m/r15m/r15s/ut/pg/ls/it/swp/io (the periodic/dynamic resval metrics) on a worker that should have real non-zero values. User's own hypothesis: this worker was running in 'virtual host mode' (xcecd_virtual, a synthetic/mocked worker used for sandbox testing, not a real xcecd against real host hardware) which may never populate these metrics with real readings; wants to validate against a real (non-virtual) xcecd worker instead, but notes the sandbox/container this session runs in needs a fix to make sudo work before that's possible (real xcecd's periodic resource collection -- disk/load/mem readings -- may need elevated privileges not currently available in this container).
Environment
Not recorded (migrated from buglog.json).
Reproduction
Not recorded (migrated from buglog.json).
Root cause
CONFIRMED, INVESTIGATION-ONLY (no code bug found -- design is correct, working as intended): sudo -n true fails in this sandbox (sudo: unable to initialize PAM: Critical error - immediate abort, exit 1) -- confirmed non-interactively this session, real (non-virtual) xcecd cannot be brought up here (its check_user() unconditionally requires geteuid()==0 for the production binary). Fell back to code-level determination, and it is conclusive: worker/meson.build shows xcecd and xcecd_virtual are compiled from the IDENTICAL source list (xcecd_srcs, including resource_sync.c and node_information.c verbatim) -- the only difference is the -DVIRTUAL_CLUSTER preprocessor define, which (grepped across every worker .c/.h file) gates ONLY root-privilege/sqlite-db-recovery/dbus-manager/process-execution-related code paths (xcecd.c, xcecd_db.c, controller_connector.c, xcecd_dbus_manager.c, xcecd_worker_utils.c, main.c's check_user()) -- resource_sync.c and node_information.c have ZERO VIRTUAL_CLUSTER conditionals anywhere. Read every one of the 11 node_info_get_*() getters (node_information.c): all are REAL, unconditional system-reads -- read_system_loadavg() parses /proc/loadavg (r1m/r15m/r15s), read_memory_info() parses /proc/meminfo (mem), node_info_get_tmp() calls statvfs('/tmp'), node_info_get_io()'s read_disk_io_rate() parses /proc/diskstats, node_info_get_ls() walks utmp via setutent()/getutent(), node_info_get_it() reads utmp activity or /proc/uptime as a fallback -- none are stubbed, mocked, or synthesized for virtual mode. collect_load_indices() (resource_sync.c) calls these same getters unconditionally regardless of xcecd vs xcecd_virtual. This directly corroborates bug-1569 thread A's own prior, independent live finding on this exact question (already in this buglog, closed): 'step N in the REPL ... mem=16786444288.00, r1m=0.64, r15m=0.99, r15s=0.64, ut=2.08, pg=463.20, it=3341.19, tmp=65732259840.00 -- all correct; ls/swp/io legitimately 0 on this idle sandbox' -- using this SAME xcecd_virtual binary. This session's own bug-1585 live repro work independently reconfirmed it fresh, twice: (1) the scheduler log during the bug-1585 deployment showed genuinely non-zero periodic resvals flowing from worker-1 (xcecd_virtual) -- e.g. 'resval applied host=worker-1 resource=mem value=19967893504.000000', 'resource=r15s value=4.610000', 'resource=tmp value=801655111680.000000', 'resource=it value=5739.550000'; (2) after fixing bug-1585 and loading a periodic-checkpoint snapshot via the REPL, 'info worker worker-1' showed mem=18382995456.00, r1m=4.93, r15m=5.73, r15s=4.93, ut=24.26, pg=1413.87, it=5768.14, tmp=797803061248.00 -- all real, plausible non-zero values; only ls/swp/io read 0.00, exactly matching bug-1569's own 'legitimately 0 on this idle sandbox' explanation (no logged-in users in utmp, no swap configured, negligible disk I/O delta in a short idle window -- not a bug, a correct reading of an idle/minimal sandbox). CONCLUSION: the user's reported all-zero values were almost certainly the SAME REPL-query-before-step/continue methodology gap bug-1569 already root-caused and bug-1585 (this session) re-confirmed and fixed the recording-side half of -- NOT a virtual-vs-real xcecd distinction. xcecd_virtual is not designed to stub/mock these 10 metrics; it collects them for real, identically to production xcecd.
Fix
NO CODE FIX -- none needed; this is a confirmed non-bug (design is correct, resource_sync.c/node_information.c's collection code is genuinely virtual/real-mode-agnostic, verified by full source read plus two independent fresh live confirmations this session of real non-zero xcecd_virtual readings, corroborating bug-1569's own prior identical conclusion). If a live real-vs-virtual xcecd comparison is still wanted for extra certainty, it requires fixing this sandbox's sudo/PAM configuration first (out of scope for a code-level investigation) -- but given resource_sync.c/node_information.c have zero VIRTUAL_CLUSTER branching and every getter is a genuine unconditional /proc or utmp read, a real xcecd would be expected to read the SAME live host counters xcecd_virtual already does (same process, same kernel, same /proc), just without the artificial worker-name/slot-count synthesis xcecd_virtual's OTHER (unrelated) code paths add. No further action recommended unless a NEW live report of persistently-zero values is seen AFTER confirming step/continue was used correctly.
Verification
Not recorded (migrated from buglog.json).
References
- Related: bug-1569, bug-1585