42 lines
3 KiB
Markdown
42 lines
3 KiB
Markdown
---
|
|
id: "bug-1854"
|
|
status: "fixed"
|
|
status_updated: "2026-09-25"
|
|
status_note: "663ea63c"
|
|
component: "scheduler"
|
|
severity: "unknown"
|
|
timestamp: "2026-09-24T08:35:00Z"
|
|
files: ["src/scheduler/src/scheduler.c"]
|
|
tags: ["scheduler", "config-push", "rejoin", "resources", "log-noise"]
|
|
related: []
|
|
fix_commits: ["663ea63c"]
|
|
legacy: true
|
|
gitea_issue: 275
|
|
gitea_synced_status: "fixed"
|
|
gitea_synced_hash: "2c54c07e9725"
|
|
---
|
|
|
|
# bug-1854: Every HA soak run logs 'ERROR [sched_init_resources] sched_init_resources add resource <name>…
|
|
|
|
## Description
|
|
OPEN, NOT FIXED, low priority. Every HA soak run logs 'ERROR [sched_init_resources] sched_init_resources add resource <name> failed' for EVERY configured resource (~33 lines), once per scheduler process, ~30s after it joined -- i.e. when a primary failover makes the scheduler re-join and the controller re-pushes its config (231/264/429 lines in 3 soak runs today). Scheduling is unaffected in those runs (all soaks PASS, replay parity 0 mismatches).
|
|
|
|
## Environment
|
|
_Not recorded (migrated from buglog.json)._
|
|
|
|
## Reproduction
|
|
_Not recorded (migrated from buglog.json)._
|
|
|
|
## Root cause
|
|
sched_init_config() is written as a first-time initializer but runs on every config push (sched_apply_pending_config, including each rejoin's push). sched_init_resources() calls makeResource() for each config->resources[i], which fails when the name is already registered in core.resmgr (key_add of an existing key) and only logs. Consequences: (1) ERROR log noise on every rejoin; (2) latent: a rejoin/upgrade config push that CHANGES a resource definition (flags, valtype, order) never updates the scheduler's copy. Pre-existing -- the same call ran on the handler thread before bug-1846's deferral; not introduced by it. sched_init_queues() re-adding queues on each push is worth checking under the same lens.
|
|
|
|
## Fix
|
|
NOT FIXED. Candidate: on an existing name, update the registered xce_resource_t in place (or treat identical definitions as a no-op and log at DEBUG), mirroring core_events.c's core_upsert_* upsert posture for RESOURCES_PUSH; decide separately whether a changed definition needs picker/accounting refresh.
|
|
|
|
UPDATE (2026-09-25): 2026-09-25: same defect also at the core CONFIG_PUSH path -- core_events.c core_apply_config_resources() calls makeResource() per pushed resource; makeResource_() (lib/resobj.c) returns NULL/EEXIST for any already-registered name and the caller logs ERROR 'core_apply_config_resources add resource <name> failed'. Seen as 33 ERROR lines in data/scheduler-replay-20260925-133708.replay (sim --sim-verify, b63bb581): the scheduler rejoined at 13:39:27 and the controller re-pushed CONFIG (plus WORKERS/JOB_PUSH) onto a core whose resources were already registered. Verify 0 mismatches, all 60 jobs DONE -- noise only in that run. A fix must cover both sites (sched_init_resources and core_apply_config_resources): identical definition -> no-op at DEBUG; changed definition -> decide update-in-place vs loud WARN.
|
|
|
|
## Verification
|
|
_Not recorded (migrated from buglog.json)._
|
|
|
|
## References
|
|
- Gitea: #275
|