Re: Question About the Purpose of s6-rc

From: Uros Perisic <uros.m.perisic_at_gmail.com>
Date: Fri, 20 Mar 2020 15:04:00 +0800

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 <colin_at_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
>
Received on Fri Mar 20 2020 - 07:04:00 UTC