Alright, I'm sold. I'm diving into s6. So much control. Thanks again Colin!
On Fri, Mar 20, 2020 at 2:33 PM Colin Booth <co...@heliocat.net> wrote: > 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 >