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.