So this appears to be a basic assumption in watchfrr.c that zebra is being started. Since it looks like you are going to run BGP as a Route Reflector, I would recommend adding `zebra=yes` to your `/etc/frr/daemons` file and making sure you create your bgp instance as a view to avoid passing data to zebra. In the meantime we need to have a bit of a discussion about whether or not this makes sense to continue having watchfrr.c assume that zebra must be running. donald On Wed, Sep 19, 2018 at 12:48 PM, Donald Sharp <sharpd@cumulusnetworks.com> wrote:
François -
I've recreated the issue and am currently scratching my head about what is going on. I'll continue debugging in the meantime.
donald
On Tue, Sep 18, 2018 at 1:05 PM, François <francois.serman@corp.ovh.com> wrote:
Hi again,
do you have any hint on what could be wrong, or should I dig into the code?
Thanks :)
----8<---------------------------------------------------------------------------
On Fri, Sep 14, 2018 at 03:04:17PM +0200, François wrote:
On Fri, Sep 14, 2018 at 08:40:58AM -0400, Donald Sharp wrote:
Yes it does look that way. We'll need the output of `journalctl -f` during startup as well as any log files generated by FRR during this time.
There's a lot of noise in those logs due to network not being totally configured, but everything is available at http://paste.debian.net/hidden/2cf176ff/
There is "nothing" specific in the frr config. I didn't do any configuration for watchfrr (see below). And only bgpd is started in /etc/frr/daemons. There's one mention of watchfrr in the /etc/frr/daemons.conf :
# The list of daemons to watch is automatically generated by the init script. watchfrr_enable=yes watchfrr_options=(-d -r /usr/sbin/servicebBfrrbBrestartbB%s -s /usr/sbin/servicebBfrrbBstartbB%s -k /usr/sbin/servicebBfrrbBstopbB%s -b bB)
Thanks for you help :)
-- François
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev