As of F25, the 'tc' command was moved to a separate sub-package of
iproute, which must be included both at build- and run-time.
Signed-off-by: Gabriel Somlo <glsomlo@cert.org>
Allow native distribution packages to run with their default user
and group names by no longer forcing "-u root -g root" on any of
the Quagga daemons' command lines.
This should continue to allow hand-compiled and/or "side-loaded"
Quagga software to run as root, if configured to do so at build
time.
Signed-off-by: Gabriel Somlo <glsomlo@cert.org>
Since all Quagga daemons are configured from a consolidated
location (the 'zebra' service), there is nothing left to do
for a dedicated service such as 'vtysh'. This patch removes
the service, along with all references to it from the rest
of the source tree (sample *.imn files, examples, etc.)
Signed-off-by: Gabriel Somlo <glsomlo@cert.org>
Currently, all Quagga daemons are started concurrently by their
respective CORE services, using "quaggaboot.sh" generated by the
'zebra' service. However, all routing services depend on 'zebra'
already running, and 'vtysh' depends on ALL other Quagga services
before it can push configuration from the common "Quagga.conf" to
all running daemons (see "waitforvtyfiles()" in "quaggaboot.sh").
The spinwait+timeout based implementation of "waitforvtyfiles()"
may, depending on load, give up too early and fail to configure
all Quagga daemons.
This patch streamlines the way Quagga daemons are started, by
launching them all from the 'zebra' service. The correct sequence
is to first launch the 'zebra' daemon itself, then proceed with
all routing daemons, and finish with a call to "vtysh -b" which
configures all running daemons.
The list of all applicable daemons to launch is obtained using
'grep' from Quagga.conf, in the same way "waitforvtyfiles()" used
to discover which *.vty files to look for in /var/run/quagga/.
The startup command for all services other than 'zebra' becomes
empty, and "quaggaboot.sh" issues a warning on attempts to have
it launch any other daemon.
Signed-off-by: Gabriel Somlo <glsomlo@cert.org>
On distributions using systemd, a default limit on the number of
tasks allowed to be created from a given unit may be set by default
(e.g., on F24, "DefaultTasksAccounting=yes" and "DefaultTasksMax=512"
are set in /etc/systemd/system.conf. A large CORE simulation may well
exceed that limit, at least during startup when many (sub)shell
processes are generated using fork().
To avoid running into this limit, set "TasksMax=infinity" in the
core-daemon.service unit file template.
Signed-off-by: Gabriel Somlo <glsomlo@cert.org>
