On Fri, Mar 20, 2020 at 01:36:13PM +0800, Uros Perisic wrote:
> Thanks Colin!
>
> That clarifies a lot.
>
> The s6-rc -wu command was a typo, although I had no clue s6-rc has such an
> option as well, so the information is still useful. I meant to say s6-svc
> -wu <service>. Or am I wrong in assuming that that is the equivalent of
> runit's sv up <service>? I went that route because that is the recommended
> way to handle dependencies in runit. I take it s6-svwait is preferred in
> s6, especially given that there is no polling and hence no cost involved?
The s6-rc command for "bring everything up" is actually `s6-rc -ua
change'. I don't manually run s6-rc commands that often so I have to
look up the exact command syntax pretty often.
For light service interdependencies someting like `s6-svok
<otherservice> && s6-svwait -U <otherservice>' is the most
straightforward way to do it. You can do `s6-svc -wU <otherservice>'
instead but that's mixing control and monitoring interfaces so better to
use s6-svwait which only deals with monitoring. Both s6-svc -wU and
s6-svwait -U are roughly equivalent to synchronizing with `sv check
<otherservice>' but use the native readyness protocol within s6 instead
of depending on an external check script. Of course, you can use
s6-notifyoncheck if you need check script functionality, though that too
wires into the s6 notification protocol.
Do note that waiting on `s6-svc -wu -u' or `sv up' is mostly pointless
and waiting on `s6-svc -wu' without the -u is entirely pointless except
in one specific case. The semantics of up/-wu (vs start/-wU) are such
that sv/s6-svc will return as soon as the run script itself is launched,
not when the check has passed. Technically, `sv up' is the same as
`s6-svc -u', aka purely asynchronous, but in all but the most extreme
cases -wu should return within a few hundreths of a second since all
you're waiting on is s6-supervise getting the message and launching
./run. The only time that blocking on `s6-svc -wu' makes sense is if you
have a service that's explicitly down and you want to keep something
else from starting until you bring the first up. And then, you might as
well use s6-svwait since it'll be much clearer what you're doing.
Under the hood, s6-svc -w? forks s6-svwait -?, which itself forks
s6-ftrigrd to monitor the event/ directory. As such, using s6-svc -w?
without a command is equivalent (though slightly slower) than using
s6-svwait directly.
--
Colin Booth
Received on Fri Mar 20 2020 - 06:33:51 UTC