Some technical thoughts on init & service launching/supervision systems: most dependencies & ordering relationships are bogus.
A common antipattern is for stuff to depend on network or another service being up, but either this is a fake dependency or a bug.
Network for example can have blip or outage at any time. A dependency on it coming up is inherently a TOCTOU race. But no decent sw cares. It already handles ups & downs gracefully.
This is why my boot script is basically just a & b & c & d & e & (& = background).
@dalias most software does not meet your criteria for decent
I can't find it right now, but your minimal init that basically just kicks off some scripts, and then just lives to reap zombies is nice and clean.
@dalias
Interesting. The networking example is really good.
What do you think of mount points. Is there a simple way for the software to wait until the correct mount points are available?
@sertonix The mount point should come up immediately with no network or device access and block on accesses while the underlying resource is intermittently unavailable.
If it's synchronous, you have a blip-leading-to-boot-failure condition.
@dalias As far as I know the mount command blocks until the resource is available. Is there an option/event to only wait until the mount point is there?
@sertonix Implementing the fs backend in FUSE rather than using the kernel NFS impl?
(Not necessarily a serious suggestion, just indicative of where problem is.)
To answer my own question here: I think (or at least hope) that autofs can be used to reserve mount points for later use.
https://www.kernel.org/doc/html/v6.12/filesystems/autofs.html
There is however the risk of a deadlock when there is a recursive dependency.
@lanodan I've never used openrc to do that, and what I like about it is that it didn't make me do so. I can just use ifup/down or even ifconfig.