What about a `dnsmasq' service depending on serveral `dnscrypt-proxy'
instances for failover, and can start when any of the instances become
ready?
Call it bad faith from me, or whatever you like, but I really dislike
the
idea of implementing disjunctions at the service manager level.
Disjunctions
create nondeterministic startup sequences, which can lead to heisenbugs
faster than you can say "systemd".
For that use case, I would delegate the disjunction to the service
itself.
I would have a unique "dnscrypt-proxy" service handling the failover
instances itself, and "dnsmasq" would depend on that "dnscrypt-proxy"
service.
The failover instances can still be supervised and managed by regular
s6
primitives; s6-rc would just not see them as separate services.
If that kind of setup can be generalized, I'm not opposed to adding a
"failover instance manager" set of programs to s6, because I believe
it's
reasonably in scope. I would much rather do that than add disjunction
management to s6-rc.
--
Laurent
