myxce/.wolf/bugs/bug-1974.md

id	status	status_updated	status_note	component	severity	timestamp	last_seen	occurrences	files	tags	related	fix_commits
bug-1974	fixed	2026-10-27		controller	wrong-result	2026-10-27T03:35:12Z	2026-10-27T03:35:12Z	1	src/controller/cluster.c src/controller/worker.c src/xceadmin/src/xcecommon/mapping.py	config flags E2 external-license	bug-1854 bug-1973	2fcacac2

bug-1974: config activation kept stale resource definition (flags=0): daemon pushes refused with -EPERM

Description

Observed: Controller log on t1 after re-pushing a corrected cluster.bin (extlic mapped with location: [external] → flags SHARED|GLOBAL|EXTERNAL):

[ERROR] [log_update_resval_failure] update_resval `extlic': Operation not permitted

Expected: update_val_res' SHARED branch routes a host=="" resval for a SHARED-flagged resource into c->sharedinst; with correct flags the push lands.

Impact: the extres daemon's pushes were permanently refused on a controller whose registration predated the flag fix — the stale shape was frozen for the process lifetime, so re-pushing a corrected config did not heal it.

Found by: E2 Phase 1 live E2E on t1.

Environment

• OS: Ubuntu 24.04.2 LTS; kernel Linux 6.8.0-147-generic x86_64
• libc: glibc 2.42 (de-nix deployment closure)
• Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
• Build: debug (build.dbg)
• Code: feature/license-resources @ ba42fdd8-dirty
• Deployment: t1 single-node; xceesd extres daemon

Reproduction

1. Register extlic with flags=0 (see contributing factor below)
2. Push a corrected cluster.bin where extlic has SHARED|GLOBAL|EXTERNAL
3. xceesd pushes extlic=4 (host=="")
4. Controller: update_resval 'extlic': Operation not permitted (-EPERM)

• Frequency: deterministic (persists until controller restart or the bug-1973 fix)
• Evidence: controller log lines quoted above (t1, 2026-10-26 18:40/18:45)

Root cause

Two compounding factors:

1. Producer: the DEPLOYED xceadmin venv (/opt/xce-denix/share/xce/ xceadmin-venv) carries a stale mapping.py with NO resourcemap handling (83-line diff vs tree) — cluster bins it builds carry flags=0 for every resource. Ops issue, fixed by building with the tree venv (src/build.dbg/xceadmin/.venv/bin/xceadmin); the deployed venv still needs redeployment.
2. Controller: even with a corrected bin, cluster_build_resources() treated an already-registered name as "nothing to do" (bug-1854's RES_APPLY_CHANGED was reported but never applied), so the stale flags=0 shape survived every activation.

Fix

cluster_build_resources() now applies RES_APPLY_CHANGED by updating the registered object's definition fields (valtype/ordtype/flags/interval) in place under the resmgr write lock — none of them touches the registration slot (idx) or accumulated accounting; mirrors reconcile_config_queues' "updated by configuration activation" in-place refresh precedent. (Same loop as bug-1973's fix.) Producer side tracked separately as ops follow-up: redeploy the xceadmin venv.

Verification

• Test: test_reconcile_resources_hot_applies_changed_definition (src/controller/testsuite/test_config_resource_reconcile.c); RED before (flags stayed 0x00), GREEN after (0x1C, idx preserved).
• Suites: controller testsuite 1358 tests, 0 failures (build.dbg).
• Live: t1 — bin rebuilt with tree venv (gen=15) + fix deployed; xceesd push landed (extlic=4 in resources distribution list), rusage[extlic=3] job RUN.

References

• Related: bug-1854 (resourceApplyDef change-detection), bug-1973 (same loop's EEXIST abort), worker.c update_val_res guard (the -EPERM surface)