On Mi, 15.06.22 07:31, Kevin P. Fleming (ke...@km6g.us) wrote:
> I've got a number of systems that use BIRD to learn the routes
> available on their networks, and as a result some services on those
> systems attempt to start up before the routes have been learned. If
> those services attempt to
On Wed, Jun 15, 2022 at 5:03 PM Barry wrote:
> To be robust why not make the services recover from network issues?
> Then you do not need to care about the routes.
> Of course you will need to know if services have outages.
>
> Even if a route was working at some point what do you do if the route
> On 15 Jun 2022, at 12:32, Kevin P. Fleming wrote:
>
> I've got a number of systems that use BIRD to learn the routes
> available on their networks, and as a result some services on those
> systems attempt to start up before the routes have been learned. If
> those services attempt to make
Thanks, that pretty much matches my thinking. There's a lot of
potential complexity here.
Another way to approach this would be to specify addresses (endpoints)
that must be reachable (for some definition of reachable: ICMP ping,
TCP open, etc.), and then the monitoring tool would run an initial
I think it's better to use a custom tool. RequiresMountsFor relies on
knowing the exact mount points from the beginning and just waiting for them
to be done – but that might not exactly match networking, where you might
have two /24 routes today and a /23 tomorrow, so you can't exactly
predefine
I've got a number of systems that use BIRD to learn the routes
available on their networks, and as a result some services on those
systems attempt to start up before the routes have been learned. If
those services attempt to make network connections (even just DNS
queries), they will fail, and
