From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
	by lore.proxmox.com (Postfix) with ESMTPS id 6A4311FF15E
	for <inbox@lore.proxmox.com>; Tue,  8 Apr 2025 21:46:49 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
	by firstgate.proxmox.com (Proxmox) with ESMTP id F314435887;
	Tue,  8 Apr 2025 21:46:44 +0200 (CEST)
Date: Tue, 8 Apr 2025 21:46:10 +0200 (CEST)
From: Stefan Hanreich <s.hanreich@proxmox.com>
To: Stoiko Ivanov <s.ivanov@proxmox.com>,
 Thomas Lamprecht <t.lamprecht@proxmox.com>
Message-ID: <1069087022.1570.1744141570375@webmail.proxmox.com>
In-Reply-To: <20250408214228.0828b3d0@rosa.proxmox.com>
References: <20250408163250.355449-1-s.hanreich@proxmox.com>
 <20250408163250.355449-2-s.hanreich@proxmox.com>
 <6b9dd950-f2fe-4397-b5b6-09f4578abcc7@proxmox.com>
 <20250408214228.0828b3d0@rosa.proxmox.com>
MIME-Version: 1.0
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.6-Rev75
X-Originating-Client: open-xchange-appsuite
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.663 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DMARC_MISSING             0.1 Missing DMARC policy
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
 http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
 information. [proxmox.com, evpnplugin.pm, multi-user.target]
Subject: Re: [pve-devel] [PATCH pve-network 1/1] frr: enable frr service on
 reloading the controller config
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>


> On 08.04.2025 21:42 CEST Stoiko Ivanov <s.ivanov@proxmox.com> wrote:
> 
>  
> On Tue, 8 Apr 2025 20:43:17 +0200
> Thomas Lamprecht <t.lamprecht@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@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.

It certainly wouldn't hurt and your points sound sensible, I'll send
a v2 early tomorrow. Thanks for looking into this further!

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


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel