Re: Looking for an advice on file location in Fedora
On Wed, Mar 20, 2019 at 02:18:32PM +0100, Michal Ruprich wrote:
On 3/20/19 2:06 PM, Neal Gompa wrote:
> On Wed, Mar 20, 2019 at 9:00 AM Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)in.waw.pl> wrote:
>> On Wed, Mar 20, 2019 at 10:44:53AM +0100, Michal Ruprich wrote:
>>> Hi,
>>>
>>> I am preparing FRR so that it could be added to Fedora and since there
>>> are a lot of experienced packagers here, I would like to ask for an
>>> advice. FRR is a fork of quagga and it provides a couple of routing
>>> daemons(bgp, isis, odpf, rip, eigrp etc.). Originally in quagga, each
>>> daemon had its own binary in /usr/sbin and each daemon could be started
>>> via systemctl(including the zebra daemon which is needed to run other
>>> routing daemons). In FRR the developers have chosen a different
>>> approach. They provide a script that takes care of the start-up of all
>>> requested daemons - that means that all daemons are started via a single
>>> systemctl command.
>> That doesn't sound like a good idea. It seems that they reimplement
>> daemon management internally, which usually doesn't go well.
>>
> I've experienced this from a number of other projects. This is a
> seriously bad idea. Have you asked the FRR developers why they feel
> they can't use the service management facilities of systemd
> effectively?
Yes I have, this is their answer:
*
We see it as “one package”, not as a collection of multiple packages.
Ie. Postgresql runs multiple processes, but has 1 startup service/script
Similar, we wanted one master init/systemd script to start all daemons.
Irrelevant.
Systemd is kind of braindead on monitoring and restarting
daemons.
Things we need, but could not get done with systemd:
1) Our desire is to move to one config file (frr.conf) instead of
one per daemon in the near future and in such a config, the startup
script needs to reload the configs with vtysh after the daemons are
started. This is (not yet) the default for the main distro, but
the agreed on future.
It's always possible to reload the daemons one by
one.
systemd even has PropagatesReloadTo= to make this easy.
2) watchfrr (or on Quagga: watchquagga) is much better in
monitoring
the daemons than systemd. It has hooks into the daemons to check
if they are actually responding (and not just “running”) and trigger
restarts as needed. Watchfrr also does watchdog timers back to systemd
No need
to throw out the baby with bath water. The monitoring can easily
be done "on top" of systemd, i.e. have the monitoring daemon do its
thing and call out to systemd to restart services if it detects a process is
misbehaving. Implementing it this way is much less work, because the monitoring
daemon only needs to do status checks and a thin interface to systemd to do
the rest.
3) The order of the startup matters in some cases (i.e. with
integrated
config where we load config at the end)
Systemd is all about order and
dependencies and can bring up the units
in any requested order (or in parallel).
4) There is a reload command which can do a non-intrusive reload
without
restarting any daemons and do a differential config apply.
ExecReload= ?
5) Many distro’s don’t like systemd and we figured that
maintaining one
(complex) init script is easier than multiple scripts. (I’m still
tasked to somehow combine the debian and red hat init scripts into
one single one if somehow possible, but didn’t get around it.
Hmm, did they
notice that Debian switched to systemd by default a while
back and sysvinit is on life support? It sounds like the upstream is severely
misguided, and is putting a lot of development work into something which
has no future.
Zbyszek