These subprocesses don't use frr_config_fork(), so frr_is_after_fork is
never set. While the frr_pthread stuff isn't currently used there, set
the flag anyway to avoid future headaches.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Creating any threads before we fork() into the background (if `-d` is
given) is an extremely dangerous footgun; the threads are created in
the parent and terminated when that exits.
This is extra dangerous because while testing, you'd often run the
daemon in foreground without `-d`, and everything works as expected.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Turns out the PCEP stuff does not work particularly well if its threads
are ... missing. Who would've thought?
Reported-by: Erik Kooistra <me@erikkooistra.nl>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
... for any initialization that needs to run after forking, but that
would be racy if it were just scheduled on the thread_master (since the
config load is also just a thread callback, ordering would be undefined
for another scheduled thread callback.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
very_late_init doesn't really say what this does, config_post is much
more descriptive. (A config_pre is coming in a jiffy.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
`CFLAGS` is a "user variable", not intended to be controlled by
configure itself. Let's put all the "important" stuff in AC_CFLAGS and
only leave debug/optimization controls in CFLAGS.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
... by referencing all autogenerated headers relative to the root
directory. (90% of the changes here is `version.h`.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When I run frr-reload.py I am seeing this error:
Apr 21 06:23:51 eva frrinit.sh[3776992]: /usr/lib/frr/frr-reload.py:1094: SyntaxWarning: "is not" with a literal. Did you mean "!="?
Apr 21 06:23:51 eva frrinit.sh[3776992]: if line is not "exit-vrf":
fix
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Otherwise it aborts with "File does not reside within any path specified
using --proto_path (or -I)"
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Issue: When maximum-path is configured in ospf6 view, the
function ospf6_restart_spf deletes the external table as well
which is not required since that stores the redistribute routes.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
abort() raises SIGABRT, which would confusingly cause a 2nd backtrace to
be printed after the first one...
Signed-off-by: David Lamparter <equinox@diac24.net>
When oi->area == NULL, it tries to print the
interface's area name, but no area is present.
Print the area name from the command argument instead.
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
Absolutetly cosmetic change, but let it be consistent with other checks
for optional attributes.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Specifying watchfrr as CMD instead of ENTRYPOINT allows one to easily
override this command when starting a docker container. This allows
simple, manual testing via (e.g.) bash. With ENTRYPOINT only the
container will simply explode with an exit code if watchfrr exits.
For instance one could start a shell session in this container via:
```
docker run --name test --rm -i -t <frr-container> bash
```
The default behavior (`docker run <frr-container>` with no command
specified) is not changed.
Signed-off-by: Wesley Coakley <wcoakley@nvidia.com>
Compiler warns about uninitialized value, although in practice it is
unreachable.
Also updates a function comment explaining what that value does.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
More of a demo on what to do with the frr.xref file, but also slightly
useful in finding vtysh SNAFUs :)
Signed-off-by: David Lamparter <equinox@diac24.net>
