FRR reload script is not executed properly
I deleted frr Neighbors through webgui, but it was not deleted in frr.
That is, the deletion operation through pf webgui is not reflected in the frr routing system
built on Tue Sep 05 05:55:55 UTC 2023
We had the same issue when using FRR OSPF. It seems that the "frr-reload" script that is used to communicate config changes to the frr daemon does not work anymore due to the "frr-reload.py" script being moved to another location in some release.
According to the script, "frr-reload.py" is expected at /usr/local/lib/frr/frr-reload.py while it actually is at /usr/local/sbin/frr-reload.py
A quick workaround was to create a symlink to make the file available at the exptected location:
ln -s /usr/local/sbin/frr-reload.py /usr/local/lib/frr/frr-reload.py
Updated by Jim Pingle 4 months ago
- Subject changed from I deleted frr Neighbors through webgui, but it was not deleted in frr. to FRR reload script is not executed properly
Looks like that's an upstream bug in the
The script at
/usr/local/sbin/frr-reload is looking for
: more /usr/local/sbin/frr-reload #!/bin/sh if test -e /usr/local/lib/frr/frr-reload.py; then exec /usr/local/lib/frr/frr-reload.py --reload /var/etc/frr/frr.conf fi >&2 echo "Please install frr9-pythontools package. Required for reload" exit 1
frr9-pythontools pkg is placing the script in
: pkg info -l frr9-pythontools-9.0.1 frr9-pythontools-9.0.1: /usr/local/sbin/frr-reload.py /usr/local/sbin/generate_support_bundle.py /usr/local/share/licenses/frr9-pythontools-9.0.1/GPLv2 /usr/local/share/licenses/frr9-pythontools-9.0.1/LICENSE /usr/local/share/licenses/frr9-pythontools-9.0.1/catalog.mk /var/etc/frr/support_bundle_commands.conf
And since the two don't match (
/usr/local/lib/frr/frr-reload.py), it doesn't work.
So then the question is... Which one is wrong? Is the script looking in the wrong place, or is the
frr9-pythontools port putting it in the wrong place?
The symlink is OK as a temporary workaround but that isn't something we would commit to the package. It needs to be addressed upstream in either the
frr9-pythontools port, and then we can bring the fix in from there.
Updated by Christian McDonald 4 months ago
Updated by Jim Pingle 3 months ago
Mike Moore wrote in #note-12:
I did add the sym link as suggested earlier up in the thread: ln -s /usr/local/sbin/frr-reload.py /usr/local/lib/frr/frr-reload.py
Should i remove that prior to upgrading the port?
It would be a good idea to clean that up to avoid any chance of a conflict.