---
id: "bug-1974"
status: "fixed"
status_updated: "2026-10-27"
status_note: ""
component: "controller"
severity: "wrong-result"
timestamp: "2026-10-27T03:35:12Z"
last_seen: "2026-10-27T03:35:12Z"
occurrences: 1
files: ["src/controller/cluster.c", "src/controller/worker.c", "src/xceadmin/src/xcecommon/mapping.py"]
tags: ["config", "flags", "E2", "external-license"]
related: ["bug-1854", "bug-1973"]
fix_commits: ["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)