[pve-devel] [PATCH pve-network 1/1] frr: enable frr service on reloading the controller config

[Stoiko Ivanov]

On Tue, 8 Apr 2025 20:43:17 +0200
Thomas Lamprecht <t.lamprecht at proxmox.com> wrote:

> On 08/04/2025 18:32, Stefan Hanreich wrote:
> > Since we now ship frr with Proxmox VE, the frr service is available on
> > the nodes but disabled on install. Prior to that users had to manually
> > install frr, which automatically enabled the service. When applying a
> > SDN configuration with an EVPN controller, we invoke systemctl restart
> > frr, which leads to the service running but still being in the
> > disabled state. This means that the EVPN setup is working until the
> > next reboot. To avoid the situation where users configure an EVPN
> > controller and everything seems to be working, until a restart breaks
> > the EVPN setup, additionally enable the frr service before restarting
> > it.
> > 
> > Signed-off-by: Stefan Hanreich <s.hanreich at proxmox.com>
> > ---
> >  src/PVE/Network/SDN/Controllers/EvpnPlugin.pm | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> > index c245ea2..4249cc5 100644
> > --- a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> > +++ b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> > @@ -638,6 +638,7 @@ sub reload_controller {
> >  	};
> >  	if ($@) {
> >  	    warn "frr reload command fail. Restarting frr.";
> > +	    run_command(['systemctl', 'enable', 'frr']);  
> 
> can we guard this with an  file exists check for
> "/etc/systemd/system/multi-user.target.wants/frr.service"? Not a must, but does
> not feel right to unconditionally call systemctl enable.
while talking off-list with Gabriel and Stefan I argued that `systemctl
is-enabled` probably costs as much as running `systemctl enable` for a
service (open socket - tell pid 1 to do stuff, wait for result) - so 
now took the time to look into it (with strace, and ignoring what pid 1
does) - in this case the output of `strace -yyttf systemctl enable frr`
vs. `strace -yyttf systemctl is-enabled frr` is around 2.5 orders of
magnitude (58k vs 9.9M) - and even for a service which does not ship an
init-script anymore (thus causing a few forks for systemd-sysv-install),
it's 56k vs 3.3M.

in any-case a `-e /etc/systemd/system/multi-user.target.wants/frr.service`
is probably the most economic version.
I tried figuring out if this check could break due to external
cirumstances - if the service is started as part of a target and that
target is pulled into multi-user.target - the symlink is not present
(e.g. zfs-zed) - but even then we'd fall back to the "expensive" enabling.

summing up - the existence check seems sensible to me as well.


> 
> >  	    eval { run_command(['systemctl', 'restart', 'frr']); };
> >  	}
> >      }  
> 
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 
>