On 24/09/2020 16:28, Simon Matter wrote: >> On 24/09/2020 13:41, Simon Matter wrote: >>>>> I've been dealing with issues like this for a while - systems with >>>>> multiple interfaces, some of which do not come up for quite a while, >>>>> and >>>>> I need to wait for all to be up before running certain tasks. Still >>>>> haven't found anything very satisfactory. >>>>> >>>>> >>>> All good points. Thank you for that douse of reality. >>> I'm just wondering, is there a chance to make this work reliable without >>> modifying the source code of systemd? >>> >>> Simon >>> >> Polling? If "some of [them] do not come up for quite a while" it would >> not be a problem to add another couple of seconds, I guess. >> >> It might be against an "event driven" aproach, but it would work and you >> can add all sorts of tests to make sure everything is ready for your job >> (eg. including reachability of remote services, etc.) > Sounds like a job for shell scripts then - or how do you integrate it with > systemd? > > I still have a lot of such stuff waiting here for being ported to the new > systemd world and I still don't really know how to do it best. > > For pretty standard things it's easy to use systemd unit files but as soon > as it gets more complicated, bash scripting feels much easier to me than > systemd unit scripting :-( Exactly: Write a service that is just a script waiting for all the things to come up and to be ready. Then do the real thing. I guess you could use that script as a target to reach and you could then wait for *that* in other services.