Page MenuHomeVyOS Platform
Create Task
Maniphest T9535

API commit-confirm with action reboot: failed commit still starts the reboot timer
Open, Requires assessmentPublicBUG
Actions

Description

Since vyos-1x#5558, the HTTP API calls commit_confirm() before commit(). With the default action reboot, a /configure request with confirm_time whose commit fails verification returns "success": false and applies nothing, but commit-confirm.timer stays active.

On the merge-base, the API called commit_confirm() only after commit() succeeded, and the same request left the timer inactive.

Steps (rolling with #5558, system config-management commit-confirm action unset, so reboot):

  1. Leave protocols bgp system-as unset.
  2. POST to /configure: {"op": "set", "path": ["protocols", "bgp", "neighbor", "192.0.2.9", "remote-as"], "value": "65001", "confirm_time": 1}
  3. The response is {"success": false, "error": "[ protocols bgp ]\nBGP system-as number must be defined!Initialized commit-confirm; 1 minutes to confirm before reload\n\n[[protocols bgp]] failed\nCommit failed\n", "data": null}
  4. systemctl is-active commit-confirm.timer reports active.

Details

Version
1.5-rolling-20261026
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Event Timeline

a.kudientsov created this task.Thu, Oct 29, 2:15 PM
pasik subscribed.Thu, Oct 29, 2:22 PM
rherold subscribed.Fri, Oct 30, 8:50 PM

Context from the discussion in vyos-1x#5558 (comments of jestabro on 2026-10-27 and 2026-10-29): starting the timer before the commit is intended for the action reboot. A failed partial commit should be rebooted, the reboot into the saved configuration is the safety net. The ticket is the part that was left open there: the API cannot tell a commit that failed before anything was applied from one that failed after some scripts ran.

What I checked in the code of the PR: run_commit_confirm() and call_commit_confirm() call commit_confirm() first. For reboot that starts the systemd timer at once (commit_confirm_start_timer()), for reload the timer is started later in the post-commit script. A failed commit raises ConfigSessionError in both cases, so the API sees the same error for both situations.

In the example of the report only the script of protocols bgp is involved, and its verify() raises, so nothing is applied. A reboot after confirm_time gives no benefit there, the router goes down for no reason.

I did not run this and I do not know which signal tells the cases apart. Things worth checking: whether the commit output or the commit status of the backend says in which stage it stopped, whether the running configuration is unchanged after the failure, and whether the timer can be stopped in that case. If none of that is reliable, the documentation of confirm_time should say that a failed commit with the action reboot reboots the router.