VyOS command definitions, scripts, and utilities (mirror of https://github.com/vyos/vyos-1x.git) https://git.amelek.net/vyos/vyos-1x.git/atom?h=rolling 2026-10-10T20:10:32+00:00 2026-10-10T20:10:32+00:00 Christian Breunig christian@breunig.cc 2026-10-10T20:10:32+00:00 urn:sha1:1748e1eff7db459bfcaa69b28862dd2740fe1745 A lease event during a commit rendered FRR from the active configuration, which the commit has not replaced yet. When the lease arrived after the commit's own FRR render but before the commit finished, the stale render was applied and nothing corrected it: moving a DHCP interface into a VRF left the VRF without its default route. The lease hook now starts the render detached and the render waits for the running commit to complete. Detaching is required, as a commit stopping the DHCP client waits for the release hook. Waiting is opt-in, as the commit itself uses the same helper when it cannot reach the configuration daemon. 2026-10-07T17:59:13+00:00 Christian Breunig christian@breunig.cc 2026-10-07T17:59:13+00:00 urn:sha1:c8d75f88f078c8c2c2a1f6a9a62c937424279d4b Reconciling the FRR configuration after a DHCP lease event was requested from the configuration daemon over the socket the commit pipeline uses. The daemon serves one client at a time and assumes it is the running commit, so the request either landed in the middle of the handshake which hands over the configuration, or kept the daemon busy past the 10ms a commit waits for it. Either way the commit fell back to running the conf-mode scripts directly. Those never render FRR, only the daemon does, so the commit succeeded while FRR kept the configuration rendered before it, until the next lease event. A lease event now renders FRR in its own process, and a commit which could not use the daemon renders FRR itself instead of skipping the reload. Both take the same lock. A commit post-hook would remove the second case, for a full render on every commit.