<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">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.<br><div dir="auto"><br></div><div dir="auto">(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...)</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 15, 2022, 14:32 Kevin P. Fleming <<a href="mailto:kevin@km6g.us">kevin@km6g.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've got a number of systems that use BIRD to learn the routes<br>
available on their networks, and as a result some services on those<br>
systems attempt to start up before the routes have been learned. If<br>
those services attempt to make network connections (even just DNS<br>
queries), they will fail, and that's unpleasant.<br>
<br>
I can't use existing systemd facilities to make these services wait,<br>
because there's no mechanism available for BIRD to indicate that any<br>
specific route has been learned, or a way to configure a service to<br>
wait for a specific route.<br>
<br>
I'm considering just writing a smallish Python program which will<br>
accept (via configuration) a list of routes, and will listen to<br>
netlink to wait for all of those routes to appear. I'd then make my<br>
services dependent on this service reporting success. However, since<br>
networkd already listens to netlink, it would certainly be possible<br>
for it to provide this facility in some way.<br>
<br>
If you'll pardon the analogy, I'm thinking of something like<br>
RequiresMountsFor=, which makes service startup wait until mount units<br>
have succeeded. Of course following this analogy we'd end up creating<br>
the concept of a 'route unit', and I'm not sure that's really the<br>
right thing to do here.<br>
<br>
Is it worth trying to design some way for networkd to provide this<br>
facility? if not, I'll just continue down the road of doing this<br>
outside of systemd proper.<br>
</blockquote></div>