---
id: "bug-1586"
status: "wontfix"
status_updated: "2026-09-24"
status_note: "not a bug: resval getters mode-agnostic, live values confirmed non-zero"
component: "worker"
severity: "security"
timestamp: "2026-08-19T02:47:00Z"
last_seen: "2026-09-19T09:00:00Z"
occurrences: 2
files: ["src/worker/src/resource_sync.c (collect_load_indices)", "src/worker/src/node_information.c (the 10+1 node_info_get_* getters)", "src/worker/meson.build (xcecd vs xcecd_virtual target definitions)"]
tags: ["worker", "resource-values", "xcecd-virtual", "environment", "sandbox", "sudo", "container", "investigation-only", "confirmed-non-bug", "code-inspection", "test-methodology-artifact"]
related: ["bug-1569", "bug-1585"]
legacy: 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