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
