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 <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 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. >
