On 3/20/19 2:06 PM, Neal Gompa wrote:
> On Wed, Mar 20, 2019 at 9:00 AM Zbigniew Jędrzejewski-Szmek
> <zbys...@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.
*
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.
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
3) The order of the startup matters in some cases (i.e. with integrated
config where we load config at the end)
4) There is a reload command which can do a non-intrusive reload without
restarting any daemons and do a differential config apply.
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.
>>> There are a couple of other scripts that are used for
>>> reloading the daemons etc. I am now wondering about where to place all
>>> relevant binary files and all the scripts.
>> Do the daemons have names that are unique enough to not cause conflicts
>> with other packages? If yes, then it should be OK to put them all in
>> /usr/bin/. (There's no reason to care about "sbin" vs "bin", since nowadays
>> both are included in $PATH.)
>>
>>> The upstream idea about the location is to put all binary files and all
>>> the scripts to /usr/lib/frr/ which does not make much sense to me.
>> It is actually a pretty good choice, except that you say that those
>> executables are supposed to be called by the users directly. If they
>> weren't, or if were only rarely, this upstream decision would be
>> appropriate. In particular, there's no effective difference between
>> /usr/libexec and /usr/lib/ffr, so using /usr/lib/ffr would be correct.
>>
> If you're going to stuff binaries in a non-PATH place,
> /usr/libexec/frr (I assume FRR is the project name, and not FFR) is
> where it should go, full stop.
>
>>> My
>>> first idea was to keep the main script in /usr/sbin and put the rest to
>>> /usr/libexec, but that would only make sense if the binaries and scripts
>>> were not meant to be run by the user, which is not the case. It is very
>>> well possible to start each daemon directly without interfering with
>>> systemd or any of the scripts. Same applies for each of the script.
>>>
>>> So the question is whether it is acceptable to keep the scripts in the
>>> /usr/sbin directory together with the binaries or whether I should put
>>> them somewhere else?
>>>
>>> I would be grateful for any ideas about this. Thanks.
> In general, this project seems like it needs some help understanding
> how services should work.
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
--
Michal Ruprich
Software Engineer
Email: mrupr...@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
