Summary
After a commit-confirm was issued and then successfully confirmed, the config-mgmt commit_confirm child process did not exit. It entered a busy state and consumed 100% of one core continuously for 12 days 17 hours, until killed manually.
The configuration itself committed and saved correctly — this is a leaked process, not a failed transaction. But on passively-cooled hardware it held the CPU package at 90 °C (crit 105 °C) for the entire period, and nothing in the system surfaced it.
Version
Version: VyOS 2026.06.22-0055-rolling Release train: rolling Release flavor: generic Built on: Mon 22 Jun 2026 00:55 UTC Build commit ID: 6f3f7b7290bb7d Architecture: x86_64 System type: bare metal
vyos-1x package version 999.0-14466-g6c0fd9909.
Hardware: fanless 6-port x86_64 appliance, 4 cores, used as a router.
Expected behaviour
Once a commit-confirm is confirmed, the timer child should terminate.
Actual behaviour
The child remains in state R, consuming ~100% of one core, indefinitely.
PID PPID ELAPSED TIME %CPU STAT COMMAND 4210 4209 12-17:16:42 12-17:06:15 99.9 R /usr/bin/python3 /usr/bin/config-mgmt commit_confirm -t=5
TIME (12d 17h 06m) against ELAPSED (12d 17h 16m) shows it was on-CPU for essentially its whole lifetime — a spin, not periodic work.
Parent, sleeping normally:
PID PPID ELAPSED STAT COMMAND 4209 4014 12-17:17:10 S sudo sg vyattacfg /usr/bin/config-mgmt commit_confirm -t=5
Evidence the confirm succeeded
The child was spawned at approximately 2026-07-27 17:42, about five minutes after boot, with -t=5 (a five-minute window). Commit revisions land inside that window:
0 2026-07-27 17:47:31 by atmarcus via cli 1 2026-07-27 17:46:44 by atmarcus via cli
/config/config.boot was written at 2026-07-27 17:47. No rollback occurred, and the system ran the confirmed configuration continuously for the following twelve days. Had the confirm gone unanswered, the rollback would have fired long ago.
Thermal impact
Before kill: Package id 0: +90.0 °C (high = +105.0, crit = +105.0) After kill: Package id 0: +71.0 °C (within 25 seconds)
Load average was exactly 1.00 / 1.00 / 1.00 throughout — one core of four. Because the router stayed fully functional and responsive, no reachability-based monitoring detected anything. The only symptom was heat.
Reproduction
Reproduced deliberately on the same system, 2026-08-09. Running commit-confirm from a non-interactive vbash session spawns the child, which immediately spins at ~99% CPU:
vbash -c " source /opt/vyatta/etc/functions/script-template configure set interfaces ethernet eth3 description 'test' commit-confirm 10 exit "
Within seconds:
PID ELAPSED %CPU STAT COMMAND 19287 02:24 98.9 R /usr/bin/python3 /usr/bin/config-mgmt commit_confirm -t=10 19286 02:24 0.0 S sudo sg vyattacfg /usr/bin/config-mgmt commit_confirm -t=10 19188 02:24 0.0 S vbash -c ...
In this reproduction the invoking vbash blocks indefinitely and the commit never applies — no new revision is created and the configuration is unchanged. Killing the child, its sudo parent and the vbash clears the condition; configuration, interfaces and routing are unaffected.
This differs from the original incident in one respect, and I want to be precise about it. In the original the commit did apply — revisions landed inside the window and config.boot was written — and only the child leaked. In this reproduction the commit does not apply at all. These may be two faces of the same non-blocking wait loop, or related but distinct defects. What both share is a commit_confirm child spinning at 100% CPU rather than sleeping.
A plain commit does not reproduce it, in either form. Tested twice on the same system through the identical harness — a normal set + commit + save completes correctly and leaves no lingering process. That points at the commit_confirm path specifically rather than at commit handling in general.
Other context:
- The original commit-confirm was issued from an interactive CLI session over SSH; the change concerned interface addressing and NAT on a WAN-side interface, and the confirm was issued normally from the same session within the window.
- The configuration is small — config.boot is 4188 bytes — so the known large-configuration slow-commit behaviour in T5388 does not apply.
- T3556 (commit-archive causing 100% CPU on boot) is a different path; commit-archive is not configured on this system.
- vyos-commitd and vyos-configd were active throughout, before and after.
Impact
- One core pegged indefinitely, per occurrence.
- On fanless hardware, sustained operation near thermal limits.
- Entirely silent — the router routes, answers and commits normally throughout, so reachability and service monitoring do not fire.
- Cumulative: each affected commit-confirm would leak another core. Workflows that use commit-confirm as standard practice for changes affecting remote access are the most exposed.
Workaround
kill the child process. Configuration, interfaces and routing are unaffected — verified: interface state and addressing were identical before and after, and the router did not drop a packet.
Possibly relevant
python/vyos/config_mgmt.py in vyos-1x implements this path:
https://github.com/vyos/vyos-1x/blob/current/python/vyos/config_mgmt.py
A spin rather than a sleep suggests the wait loop is not blocking, and that the confirm-received signal terminates the parent's wait without tearing down the child.