[systemd-devel] Waiting for network routes to appear

[Kevin P. Fleming]

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 set
of reachability checks. If any are not reachable, it would monitor
netlink to see when new routes appear, and then retry the checks. This
addresses the changes in the structure of the routes, as it doesn't
matter *how* the endpoint is reachable, as long as it is reachable.
I'm probably going to implement my custom tool in this fashion, as I
think it's a better model overall.

On Wed, Jun 15, 2022 at 9:35 AM Mantas Mikulėnas <grawity at gmail.com> wrote:
>
> 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 that in units.
>
> A custom tool could more easily express logic like waiting for any route matching the specified address, or any non-/0 route, or any route through the specified interfaces.
>
> (If you're in this situation, you probably also have several routing tables, and perhaps a ton of routes. I would not want all that memory usage in pid 1 – already went through this for systemd-networkd, and then once more for nss_myhostname...)
>
> On Wed, Jun 15, 2022, 14:32 Kevin P. Fleming <kevin at 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 make network connections (even just DNS
>> queries), they will fail, and that's unpleasant.
>>
>> I can't use existing systemd facilities to make these services wait,
>> because there's no mechanism available for BIRD to indicate that any
>> specific route has been learned, or a way to configure a service to
>> wait for a specific route.
>>
>> I'm considering just writing a smallish Python program which will
>> accept (via configuration) a list of routes, and will listen to
>> netlink to wait for all of those routes to appear. I'd then make my
>> services dependent on this service reporting success. However, since
>> networkd already listens to netlink, it would certainly be possible
>> for it to provide this facility in some way.
>>
>> If you'll pardon the analogy, I'm thinking of something like
>> RequiresMountsFor=, which makes service startup wait until mount units
>> have succeeded. Of course following this analogy we'd end up creating
>> the concept of a 'route unit', and I'm not sure that's really the
>> right thing to do here.
>>
>> Is it worth trying to design some way for networkd to provide this
>> facility? if not, I'll just continue down the road of doing this
>> outside of systemd proper.