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@xxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
