Re: Question About the Purpose of s6-rc

[Laurent Bercot]

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.


 Nitpick: (using s6-svc -uwU as an example; -u to tell s6-supervise to
bring the service up, and -wU to wait until the service is up and ready)

"s6-svc -uwU blah" rewrites itself into
"s6-svlisten1 -U s6-svc -u blah" ; it doesn't use s6-svwait.

 The difference is that s6-svlisten1 starts monitoring event/ *before*
running the s6-svc -u command, whereas s6-svwait does not synchronize
that way and could only be launched in parallel or after s6-svc. This
avoids a tiny race condition and guarantees that "s6-svc -uwU blah"
always returns as soon as blah is up (and ready).

 In the s6-svwait case it doesn't really matter because s6-svwait
always checks the state of the service before processing notifications,
but it's very important in the general notification case, see the
difference between s6-ftrig-wait and s6-ftrig-listen1.

 Anyway, yes, Colin is right: "s6-rc -u change foo" blocks until "foo"
*and all its dependencies*, whether oneshots or longruns, are up; for
a set of pure longruns this can be emulated by putting s6-svwait calls
in the run scripts (but for the teardown part you'd need to write the
s6-svc -d + s6-svwait -d sequence by hand). When your dependency graph
includes oneshots, however, you cannot really emulate the functionality.

--
 Laurent

Re: Question About the Purpose of s6-rc

[Uros Perisic]

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  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 . Or am I wrong in assuming that that is the equivalent of
> > runit's sv up ? 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
>  && s6-svwait -U ' is the most
> straightforward way to do it.  You can do `s6-svc -wU '
> 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
> ' 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
>

Re: Question About the Purpose of s6-rc

[Colin Booth]

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 . Or am I wrong in assuming that that is the equivalent of
> runit's sv up ? 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
 && s6-svwait -U ' is the most
straightforward way to do it.  You can do `s6-svc -wU '
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
' 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

Re: Question About the Purpose of s6-rc

[Uros Perisic]

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 . Or am I wrong in assuming that that is the equivalent of
runit's sv up ? 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?

All the best,
Uros


On Fri, Mar 20, 2020 at 1:00 PM Colin Booth  wrote:

> On Fri, Mar 20, 2020 at 12:30:15PM +0800, Uros Perisic wrote:
> > If all services are started in parallel, but s6-rc -wu blocks until a
> > service is up, what is the difference between simply putting it in a run
> > script before the exec call, and s6-rc figuring the dependencies out
> ahead
> > of time?
>
> Hi Uros,
>
> For simple setups (a few longruns) where you know the interdependencies
> you are absolutely correct that you could use s6-svwait(1) in run scripts
> to control ordering. The hard part comes in two parts:
> 1. when you don't know the exact dependency set but know that a service
> needs to start after a group of services (lets call it a bundle) are
> started and passing their internal checks.
> 2. if you need to have an initalization script run *after* a supervised
> program is run. For example, the udev coldplug cycle (the thing that
> detects existing hardware) needs a running udev in order to create the
> device nodes and while you could run that as a forked process in the
> udev run script, it really only has to happen once.
>
> It's these two considerations that caused s6-rc to come to being. While
> the first can be handled with a helper function library, the second
> cannot without either dumb tricks (supervised processes that set
> themselves down at termination, or exec into s6-pause, or the like) or a
> system that understands both kinds of services as well as a dependency
> ordering system.
>
> Depending on what you're trying to do, s6-rc may be entirely overkill.
> Like I mentioned at the beginning, if all you're trying to do is start a
> number of services and some of those depend on others before starting
> (for example, a collection of web services and web servers fronting
> them probably want to wait until the services have started before
> bringing up their corresponding web frontend) then blocking in the web
> server run script is totally fine since it's a self-contained service
> pair. For 90+% of the process supervision world this is good enough,
> it's only when you start managing the lifecycle of full systems
> (including containers) or very complex service interdependencies does
> the added complexity of a service manager start to make sense.
>
> Cheers!
>
> P.S. s6-rc -wu blocks until the *last* service in the start set is up.
> If you add some verbosity you'll see multiple services get started, and
> then additional ones being executed as their dependencies become
> available.
>
> (1) or s6-svstat -o ready and an exit on failure, or whatever.
> --
> Colin Booth
>

Re: Question About the Purpose of s6-rc

[Colin Booth]

On Fri, Mar 20, 2020 at 12:30:15PM +0800, Uros Perisic wrote:
> If all services are started in parallel, but s6-rc -wu blocks until a
> service is up, what is the difference between simply putting it in a run
> script before the exec call, and s6-rc figuring the dependencies out ahead
> of time?

Hi Uros, 

For simple setups (a few longruns) where you know the interdependencies
you are absolutely correct that you could use s6-svwait(1) in run scripts
to control ordering. The hard part comes in two parts: 
1. when you don't know the exact dependency set but know that a service
needs to start after a group of services (lets call it a bundle) are
started and passing their internal checks.
2. if you need to have an initalization script run *after* a supervised
program is run. For example, the udev coldplug cycle (the thing that
detects existing hardware) needs a running udev in order to create the
device nodes and while you could run that as a forked process in the
udev run script, it really only has to happen once.

It's these two considerations that caused s6-rc to come to being. While
the first can be handled with a helper function library, the second
cannot without either dumb tricks (supervised processes that set
themselves down at termination, or exec into s6-pause, or the like) or a
system that understands both kinds of services as well as a dependency
ordering system. 

Depending on what you're trying to do, s6-rc may be entirely overkill.
Like I mentioned at the beginning, if all you're trying to do is start a
number of services and some of those depend on others before starting
(for example, a collection of web services and web servers fronting
them probably want to wait until the services have started before
bringing up their corresponding web frontend) then blocking in the web
server run script is totally fine since it's a self-contained service
pair. For 90+% of the process supervision world this is good enough,
it's only when you start managing the lifecycle of full systems
(including containers) or very complex service interdependencies does
the added complexity of a service manager start to make sense.

Cheers!

P.S. s6-rc -wu blocks until the *last* service in the start set is up.
If you add some verbosity you'll see multiple services get started, and
then additional ones being executed as their dependencies become
available.

(1) or s6-svstat -o ready and an exit on failure, or whatever.
-- 
Colin Booth

Question About the Purpose of s6-rc

[Uros Perisic]

Hi all,

I am generally new to daemontools-style init systems (been a runit user for
about 6 months now, looking to try out s6), so I have a few clarifying
questions regarding s6-rc. Forgive me if they stem from my ignorance.

All three bullets here 
essentially boil down to dependency management (with the exception of
one-shot services). But my question is this:

If all services are started in parallel, but s6-rc -wu blocks until a
service is up, what is the difference between simply putting it in a run
script before the exec call, and s6-rc figuring the dependencies out ahead
of time?

Best,
Uros