Current -n option is only for zebra and mgmtd. All other daemons receive
the VRF backend configuration from zebra upon connection to it. This
leads to a potential race condition - daemons need to know the backend
before they start reading their config, but they can be not connected to
zebra yet at this point. As the VRF backend cannot change during runtime,
let's introduce a new global -w option for setting netns backend, to
make sure that all daemons know their VRF backend immediately after
start.
The reason for introducing a new option instead of making -n global is
that ospfd already uses -n for another purposes.
Signed-off-by: Igor Ryzhov <idryzhov@gmail.com>
Move the various destinations handling into lib/memory.c, include
"normal" logging as target, and make `ACTIVEATEXIT` properly non-error
as it was intended to be.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
No `zlog_fini()`, please. Getting log messages until the end is more
important than leaking memory allocated for zlog targets.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Mgmtd makes use of libyang's internal ietf-yang-library module to add
support for said module to FRR management. Previously, mgmtd was loading
this module explicitly; however, that required that libyang's
`ietf-yang-library.yang` module definition file be co-located with FRR's
yang files so that it (and ietf-datastore.yang) would be found when
searched for by libyang using FRRs search path. This isn't always the
case depending on how the user compiles and installs libyang so mgmtd
was failing to run in some cases.
Instead of doing it the above way we simply tell libyang to load it's
internal version of ietf-yang-library when we initialize the libyang
context.
This required adding a boolean to a couple of the init functions which
is why so many files are touched (although all the changes are minimal).
Signed-off-by: Christian Hopps <chopps@labn.net>
Prior to this commit stdout of a process started in a daemon mode was
attached to a calling process.
As a result a calling process hung for infinity.
Signed-off-by: Vladislav Odintsov <vlodintsov@k2.cloud>
The debug library allows to register a `debug_set_all` callback which
should enable all debugs in a daemon. This callback is implemented
exactly the same in each daemon. Instead of duplicating the code, rework
the lib to allow registration of each debug type, and implement the
common code only once in the lib.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
vtysh will print out the `stupidly large FD limit` upon
every run of the program if the ulimit is set stupidly
large. Prevent this from being displayed for vtysh.
Fixes: #16516
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Correct FRR startup counts on a daemon's vty socket to be open when the
parent process exits. The parent process waits for `frr_check_detach()`
to be called by the child before exiting. The problem is when the
`FRR_MANUAL_VTY_START` flag is set the vty socket was not opened but
`frr_check_detach()` was called anyway.
Instead add a bool option for `frr_check_detach()` to be called when the
socket is opened with `frr_vty_serv_start()`, and do so when "manually"
calling said function (i.e., when FRR_MANUAL_VTY_START is set).
The `FRR_MANUAL_VTY_START` flag is only set by mgmtd. The reason we
wait to open the vty socket is so that mgmtd can parse the various
daemon specific config files it has taken over, after the event loop has
started, but before we receive any possible new config from `vtysh`.
fixes#16362
Signed-off-by: Christian Hopps <chopps@labn.net>
Add a new start option "-K" to libfrr to denote a graceful start,
and use it in zebra and bgpd.
zebra will use this option to denote a planned FRR graceful restart
(supporting only bgpd currently) to wait for a route sync completion
from bgpd before cleaning up old stale routes from the FIB. An optional
timer provides an upper-bounds for this cleanup.
bgpd will use this option to denote either a planned FRR graceful
restart or a bgpd-only graceful restart, and this will drive the BGP
GR restarting router procedures.
Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
We're not calling any other termination functions to free allocated
memory when daemonizing except these two. There's no reason for such an
exception, and because of these calls we have the following libyang
warnings every time FRR is started:
```
MGMTD: libyang: String "15" not freed from the dictionary, refcount 2
MGMTD: libyang: String "200" not freed from the dictionary, refcount 2
MGMTD: libyang: String "mrib-then-urib" not freed from the dictionary, refcount 2
MGMTD: libyang: String "1000" not freed from the dictionary, refcount 2
MGMTD: libyang: String "10" not freed from the dictionary, refcount 2
MGMTD: libyang: String "5" not freed from the dictionary, refcount 2
```
Remove these calls to get rid of the unnecessary warnings.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Create a single registry of default port values that daemons
are using. Most of these are vty ports, but there are some
others for features like ospfapi and zebra FPM.
Signed-off-by: Mark Stapp <mjs@labn.net>
Use consistent `e_somepath` names for expanded versions of `somepath`.
Also remove all paths from `config.h` and put them into
`lib/config_paths.h` - this is to make more obvious when someone is
doing something probably not quite properly structured.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Both of these belong in `/var/lib`, not `/var/run`.
Rather hilariously, the history read in
`mgmt_history_read_cmt_record_index` was always failing, because it was
doing a `file_exists(MGMTD_COMMIT_FILE_PATH)` check. Which is the wrong
macro - it's `.../commit-%s.json`, including the unprocessed `%s`, which
would never exist.
I guess noone ever tried if this actually works. Cool.
On the plus side, this means I don't have to implement legacy
compatibility for this, since it never worked to begin with.
(SQLite3 DB location is also changed in this commit since it also uses
`DAEMON_DB_DIR`.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These functions load daemon-specific persistent state from
`/var/lib/frr` and supersede open-coded variants of similar calls in
ospfd, ospf6d and isisd to save GR state and/or sequence numbers.
Unlike the open-coded variants, the save call correctly `fsync()`s the
saved data to ensure disk contents are consistent.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This needs to be used for persistent state, which currently is misplaced
into `/var/run` / `/run` where it gets deleted across reboots.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Also:
- replace all /* fallthrough */ comments with portable fallthrough;
pseudo keyword to accomodate both gcc and clang
- add missing break; statements as required by older versions of gcc
- cleanup some code to remove unnecessary fallthrough
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Effectively a massive search and replace of
`struct thread` to `struct event`. Using the
term `thread` gives people the thought that
this event system is a pthread when it is not
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Pass context argument by value on initialization to be clear that the
value is used/saved but not a pointer to the value. Previously the
northbound code was incorrectly holding a pointer to stack allocated
context structs.
However, the structure definition also had some musings (ifdef'd out
code) and a comment that might be taken to imply that user data could
follow the structure and thus be maintained by the code; it won't; so it
can't; so get rid of the disabled misleading code/text from the
structure definition.
The common use case worked b/c the transaction which cached the pointer
was created and freed inside a single function
call (`nb_condidate_commit`) that executed below the stack allocation.
All other use cases (grpc, confd, sysrepo, and -- coming soon -- mgmtd)
were bugs.
Signed-off-by: Christian Hopps <chopps@labn.net>
- The parent of the daemonizing fork reports memleaks for the early
northbound allocations (libyang). If these were real memleaks these
would show up in the child as well; however, ignoring all memleaks in
the parent of the fork is too hard a sale. Instead, spend some CPU
cycles cleaning up the allocations in the parent after the fork and
immeidatley prior to exiting the parent after the daemonizing fork.
Signed-off-by: Christian Hopps <chopps@labn.net>
