There might be a time element(s) from
temporary list are removed more than once
which leads to valueError in certain python3
version.
commit-id 1543f58b5 did not handle valueError
properly. This caused regression where
prefix-list config leads to delete followed
by add.
The new fix should just pass the exception as
value removal from list_to_add or list_to_del
is best effort.
This allows prefix-list config has no change
then removes the lines from lines_to_del and
lines_to_add properly.
Ticket:#3490252
Testing:
Configure prefix-list in frr.conf and perform
multiple frr-reload. After first reload operatoin
subsequent ones should not result in delete followed
by add of the prefix-list but rather no-op operation.
(Pdb) lines_to_add
[(('ip prefix-list FOO permit 10.2.1.0/24',), None)]
(Pdb) lines_to_del
[(('ip prefix-list FOO seq 5 permit 10.2.1.0/24',), None),
(('ip prefix-list FOO seq 10 permit 10.2.1.0/24',), None)]
(Pdb) lines_to_del_to_del
[(('ip prefix-list FOO seq 5 permit 10.2.1.0/24',), None),
(('ip prefix-list FOO seq 10 permit 10.2.1.0/24',), None)]
(Pdb) lines_to_add_to_del
[(('ip prefix-list FOO permit 10.2.1.0/24',), None),
(('ip prefix-list FOO permit 10.2.1.0/24',), None)]
(Pdb) c
> /usr/lib/frr/frr-reload.py(1562)ignore_delete_re_add_lines()
-> return (lines_to_add, lines_to_del)
(Pdb) lines_to_add
[]
(Pdb) lines_to_del
[]
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit 9845c09d61)
The check flag of `found_pg_cmd` is already there, but not used.
So, make it really work for reload.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
(cherry picked from commit 9ea17a5d49)
From commit `411d1a2`, `bgp_delete_nbr_remote_as_line()` is added to
remove some specific bgp neighbors. But, when reloading the following
configuration, it will wrongly remove some good ones:
`neighbor 66.66.66.6 remote-as internal`:
```
router bgp 66
bgp router-id 172.16.204.6
neighbor ANLAN peer-group
neighbor ANLAN remote-as internal
neighbor 66.66.66.6 remote-as internal <- LOST
neighbor 66.66.66.60 peer-group ANLAN
```
The reason is that "66.66.66.6" is included in "66.66.66.60" literally,
then it is mistakenly thought to be a match. Just fix it with
excat match.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
(cherry picked from commit a70895e83a)
Before it was setting SDIR, which is /usr/lib/frr, but the vtysh binary is put
under bindir (which is /usr/local by default). And running `/usr/lib/frr/frr reload`
failed.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit c9bdc0c79e)
Check for value present in list before removing
as in certain python3 ValueError traceback is observed.
Traceback (most recent call last):
File "/usr/lib/frr/frr-reload.py",
line 2278, in <module>
(lines_to_add, lines_to_del, restart_frr)
= compare_context_objects(newconf, running)
File "/usr/lib/frr/frr-reload.py",
line 1933, in compare_context_objects
lines_to_add, lines_to_del
File "/usr/lib/frr/frr-reload.py",
line 1549, in ignore_delete_re_add_lines
lines_to_del.remove((ctx_keys, line))
ValueError: list.remove(x): x not in list
Ticket:#3389979
Issue:3389979
Testing Done:
With fix perform frr-relaod on frr.conf config where earlier
traceback was seen.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit 1543f58b55)
Got `ERROR: Daemon babeld is not a valid option for 'show running-config'` when using `frr-reload.py --reload --daemon babeld`.
Adds `babeld` and `nhrpd` as valid daemons.
Signed-off-by: Yuxiang Zhu <vfreex@gmail.com>
agentx can't be disabled once enabled, so we should ignore it for frr-reload.py.
```
$ /usr/lib/frr/frr-reload.py --reload /etc/frr/bgpd.conf --bindir /usr/local/bin
"no agentx" we failed to remove this command
SNMP AgentX support cannot be disabled once enabled
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This reverts commit 2000ac4075.
There were concerns that ensuring zebra stopped last led to
problems with zebra's "-r" flag, so we'll revert that for the
time being and reconsider this area.
Signed-off-by: Mark Stapp <mjs@labn.net>
There might be use cases when this would make sense, for example
running FRR in a container as a designated user.
Signed-off-by: Michal Ruprich <mruprich@redhat.com>
The backslash in `grep -q '^declare \-a'` is not needed and
causes `grep: warning: stray \ before -` warning in grep-3.8.
Signed-off-by: Marius Tomaschewski <mt@suse.com>
PIMv6 Support Bundle commands are added in support_bundle_commands.conf file.
This will help in debugging PIMv6 test Failures.
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
It will be easier to maintain a single file instead of two separate.
Also, fixes the issue when the file (/var/log/frr/frr.log) is not created
after logrotate.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
touch + chown can have a gap between the commands (or the second failed).
This could lead to unexpected permissions (root, instead of frr) for some
.conf files or directories.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If we add/modify community/large/ext lists without sequence numbers, and
doing frr-reload.py, then rules with sequence numbers (show running-config
always adds sequence numbers) will be deleted and new ones will be re-added.
This could lead to blackholing for some time.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
It already "looks" like a bitmask, but we currently can't flag a command
both YANG and HIDDEN at the same time. It really should be a bitmask.
Also clarify DEPRECATED behaviour (or the absence thereof.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The current service file configures restarts on-abnormal, which translates to "unclean signal", "timeout", or "watchdog". This patch updates it to always restart, as there's never really a time watchfrr should exit by itself at all.
Signed-off-by: Brian Rak <brak@vultr.com>
check_function_arguments_recurse() has received a new function argument
in GCC 12. Fill it in and add a compatibility wrapper.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The problem is that when we run watchfrr.sh/frrinit.sh, we get something like:
```
cat: '"/var/run/frr/staticd.pid"': No such file or directory
cat: '"/var/run/frr/babeld.pid"': No such file or directory
cat: '"/var/run/frr/zebra.pid"': No such file or directory
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2469a37f reversed the logic of the existence check for
/etc/frr/frr.conf breaking boot config loading, fix it.
Signed-off-by: Christian Hopps <chopps@labn.net>
When starting a daemon, print the full command run by the init script to
start it. This gives more information and is especially helpful when
debugging wrap commands.
Also add some more logs to vtysh_b to print the command used there,
log when we exit early because frr.conf doesn't exist, and simplify the
code path for creating the command to use.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
The explanation block for watchfrr_options was split into two blocks,
one explaining the --netns option and one making a vague statement that
the init script provides the list of daemons to start. The former can be
merged with the latter and the latter is more useful when stated as a
caveat for what you should actually use watchfrr_options for.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
We support 'wrap' variables in /etc/frr/daemons, but the explanation
given there doesn't touch on some of the subtleties of using these
variables.
The variables were designed for use with Valgrind, which has special
behavior when run with programs that daemonize; Valgrind will intercept
the fork()'d child process and run itself instead of the child. This
behavior allows it to follow the same forking semantics as the target
program.
For virtually every other wrapper, the wrap variables do not work as
demonstrated because the wrapper programs do not daemonize. If the
wrappers do not daemonize, they will block the init script. The examples
given with "perf" for example simply do not work, because perf remains
in the foreground even as it tracks forked children.
This patch adds an explanation of the behavior expected by the init
script and offers a solution for getting that behavior.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
Fix daemon shutdown broken by f0cccaa6bf. Now
we still don't complain about missing PID files but actually stop the
running daemons.
The previous fix was broken because it passed a new "--all" option to
daemon_stop which wasn't handled properly (it assumed $1 contains the
daemon name when at that time it acutally contained the "--all" option).
Plus, "--all" wasn't actually necessary, because we already passed
"--reallyall" from all_stop to daemon_stop after the daemon name.
So remove "--all" again and simply check for "--reallyall" in $2. This
should *really* fix#11317.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
Since 1686b1d486, we try to stop all daemons,
even those which are not (no longer) enabled in /etc/frr/daemons. But we
shouldn't complain about missing PID files for daemons which have never been
started and just silently ignore those.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
