Re: Question About the Purpose of s6-rc

From: Uros Perisic <uros.m.perisic_at_gmail.com>
Date: Fri, 20 Mar 2020 13:36:13 +0800

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?

All the best,
Uros


On Fri, Mar 20, 2020 at 1:00 PM Colin Booth <colin_at_heliocat.net> 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
>
Received on Fri Mar 20 2020 - 05:36:13 UTC