Re: What's the difference between s6 and s6-rc?

[Steve Litt]

On Thu, 25 Feb 2016 19:26:11 +0100
Laurent Bercot  wrote:


>   Do you think a glossary page would help? 

Yes yes yes yes YES!!!

SteveT

Steve Litt 
February 2016 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key

Improving http://skarnet.org/software/s6-rc/why.html

[Steve Litt]

Hi all,

I find http://skarnet.org/software/s6-rc/why.html too dependent on
phrases that aren't well enough defined, and phrases that are too
similar.

For the purpose of *this one email thread* I'm going to define a
"Process Grand Supervisor" as a grand process that runs a bunch of
"Process Supervisors", that in turn run, rerun, turn on and turn
off, and output status of the processes they supervise. In other words:

Process Grand Supervisor
 |
 `Process Supervisor (many)
   |
   `Process (1, or 2 if there's a ./log)

The Process Grand Supervisor runs the Process Supervisors in parallel,
with ordering completely undefined.

A "Supervision Suite" should be defined as all the software to
implement, run and control both the Process Grand Supervisor and the
Process Supervisors. Extreme care should be taken never to use
"Supervision Suite" in place of Process Grand Supervisor. In the Runit
world, Process Grand Supervisor=runsvdir, while Supervision Suite
refers to the entire Runit package. These definitions need to be used
consistently.

A "Process Ordering Facility" (for the purposes of this one email
thread) is software that can be added to a Process Grand Supervisor
for the purpose of defining which order Process Supervisors are run.
The Process Ordering Facility can take many forms, three of which are:

* Shellscripts that run before the Process Supervision Suite is
  started (like Runit's 1 and 2 files)
* Manipulation of down files (like LittKitt)
* Another kind of addition, added to an existing Process Supervision  

From what I understand, a Process Ordering Facility is a small part
added to a Process Grand Supervisor. It does not contain a Process
Grand Supervisor, nor is it a form of Process Grand Supervisor (has-a
relationship). It's something you bolt on to a Process Grand Supervisor.

Continuing on definitions, I think things that run should be called
either "processes" or "daemons" or "services", but only one of those
words should be used throughout, and no attempt should be made to draw
any distinction between any of the three. Already, people on all sorts
of communication venues use these words interchangeably, and then
others try to appoint some sort of arbitrary distinction, and the whole
thing is a swamp of misunderstanding. Personally, I'd vote for
"process" as the one and only word, but an argument could be made that
the Process Supervisor and Process Grand Supervisor are also processes,
so the thing supervised by the Process Supervisor should be called the
"service." Personally, I see no reason to ever use the word "daemon".
For the rest of this email I'll use "service" for the thing run by the
Process Supervisor...

There are two kinds of services:

* Oneshot services
* Long-run services

These phrases are crystal clear and have been used forever in this
community. One could also make the point that there could be foreground
services: I'll worry about that later.

There are other definitions that need to be clarified and consistently
agreed upon: init system (there's a special place in hell for the fool
who says "init" when he means sysvinit), PID1, "daemonizing" for those
fools who think backgrounding should be evidence of readyness, and
probably others. I leave that for another time.


WHY THIS MATTERS

A lot of people have gone to a lot of trouble to make excellent
Supervision Suites and init systems that use Process Supervision
Suites. This fact assumes new importance as more people get
sidetracked, misled, or dragged kicking and screaming to systemd:

http://skarnet.org/software/s6/systemd.html

The trouble is this: Nothing in any existing Process Supervision Suite
docs of which I'm aware showcase the robust and simple architecture
bestowed by Process Supervision Suites and the init systems they [help]
facilitate, unless the reader has quite a bit of familiarity with the
situation, and the discipline to read *a lot*.

Which is bad news, because most people who could benefit from an init
featuring a Process Supervision Suite are a lot more like me
than they are most of you. If they're lucky, their knowledge of Process
Supervision Suites is "Yeah, daemontools is that thing you have to
install to get djbdns to run." If they're unlucky, they ask "What's a
Process Supervision Suite? What's daemontools?" When confronted with
today's Process Supervision Suite documentation, their eyes would
quickly blur with all the undefined concepts, the similarly worded
undefined concepts, and the lack of diagrams or other explanation of
relationships. And they'd figure "Hey, systemd works OK, I'll stay
where I am."

And then the Redhat/Freedesktop contingent would get even more power to
consumer more of the Linux low level programming, to the point where
using a Process Supervision Suite would preclude a system most people
want to have.
 
SteveT

Steve Litt 
February 2016 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key

Re: What's the difference between s6 and s6-rc?

[Steve Litt]

On Thu, 25 Feb 2016 16:02:11 +0100
Laurent Bercot  wrote:

> On 25/02/2016 15:47, Steve Litt wrote:
> > Could somebody, in one or two sentences, tell me the difference
> > between s6 vs s6-init?
> > I'm not looking for references to big old documents: I'm looking for
> > one or two sentences telling me the difference.  
> 
>   Still, big old documents have all the information you need, and
> more: the first lines of http://skarnet.org/software/s6-rc/why.html
> would answer your question.
> 
>   s6 is a process supervisor. It manages daemons.
>   s6-rc is a service manager. It manages the global state of a
> machine: what service is up, what service is down, with dependencies
> between services, and "services" being implemented by either a daemon
> or a one-shot script.
> 
>   s6-rc is a management layer running *on top of* s6. It uses the s6
> infrastructure to do its job, but this job is not the same at all.

:-)

Expecting responses like the preceding, I specified 1 or 2 sentences.
Luckily, Jan Bramcamp answered my questions in 2 sentences, and then
went on to give even more details, so I now feel confident in
understanding the difference between the two.

Understanding http://skarnet.org/software/s6-rc/why.html depends on
understanding the exact meanings of "supervision suite" and "service
manager", two phrases sounding confusingly similar to me (and I doubt
I'm the only one). Also confusing is sometimes use of "supervision
tree", which I assume is a synonym for "supervision suite." And then in
your email reply (above), you refer to "process supervisor", which I
assume is yet another synonym for "supervision suite."

I wouldn't have understood http://skarnet.org/software/s6-rc/why.html
before reading Jan's 2 sentence explanation (with additions). Now I do.

I'll write more about this in a separate email...

Thanks,
 
SteveT

Steve Litt 
February 2016 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key

Re: s6-rc setup

[Laurent Bercot]

On 25/02/2016 16:03, Jan Olszak wrote:

One of the reasons I think I need s6-rc is a race between starting logger
and starting the services that need logging. I need to be sure I get every
log produced and the example logging service from s6 looks awesome.
Does the logging from s6-linux-init setup in stage1 work the same way as
the example from s6? Does it use s6-log?


 Yes, s6-linux-init is a direct implementation of the stage 1 init and log
tricks described in http://skarnet.org/software/s6/s6-svscan-1.html

 The catch-all logger uses s6-log, but you can change its run script if you
want to use something else.



Do I need to have a separate logging service if one was already created in
stage1?


 Strictly speaking, you don't need to, because the catch-all logger, by
definition, will catch everything. However, I wouldn't recommend this setup:
the catch-all logger writes into a tmpfs (it has no choice: no writable
filesystem is mounted by the time it starts), so you have to choose between
eating a lot of RAM or having potentially quick rotations. RAM is not a good
place to store logs.

 I recommend having a dedicated logger for every service that justifies one,
i.e. every service that writes a non-negligible amount of logs.
 That in addition to a syslogd service, if you have daemons that log through
syslog().

--
 Laurent

Re: s6-rc setup

[Jan Olszak]

>
> So far I've done as little as possible in inittab (syslog, getty, mounts)
>> + s6-svscan starts all other stuff.
>>
>
>  You can run your gettys and syslogd under s6 too. :)
>
>
One of the reasons I think I need s6-rc is a race between starting logger
and starting the services that need logging. I need to be sure I get every
log produced and the example logging service from s6 looks awesome.
Does the logging from s6-linux-init setup in stage1 work the same way as
the example from s6? Does it use s6-log?
Do I need to have a separate logging service if one was already created in
stage1?


>
> s6-svscan doesn't run with PID 1. It's started in inittab.
>>
>
>  This doesn't change anything, s6-rc will work with that setup too.


Awesome


>
> So can I setup s6-rc + initd and later use s6-linux-init? Would that add
>> any work compared to doing both at the same time?
>>
>
>  No, those are completely independent steps. However, if you intend
> to replace sysvinit at some point, you will need to migrate the services
> that are currently supervised by it into services supervised by s6
> (and possibly managed by s6-rc).
>
>
This simplifies my work a lot, thanks!

Re: What's the difference between s6 and s6-rc?

[Jan Bramkamp]

On 25/02/16 15:47, Steve Litt wrote:

Hi all,

Could somebody, in one or two sentences, tell me the difference between
s6 vs s6-init?


For the subject i infer that you're asking for the difference between s6 
and s6-rc because there is no project or binary named s6-init.



I'm not looking for references to big old documents: I'm looking for
one or two sentences telling me the difference.


s6 is a collection of tools. Together these tools implement service 
supervision. One of those tools is s6-svscan. It scans a service 
directory and starts one s6-supervise process per service. It can also 
serve as pid 1 (aka init) of a unix system.


While s6 is a good service supervisor on its own it lacks service 
management. s6 can only track running processes and offers no ordering 
between them. You can block in a ./run script until all your 
dependencies are fulfilled or just exit and retry until it works. 
Writing this logic in every ./run script is a burden on the user but 
manageable.


On its own s6 can't track state not represented by a running process 
e.g. a mounted file system. This forces a system booting with just s6 to 
run a (possibly very small) script before s6-svscan can take over. 
Dependencies can only be modeled between running processes. This is good 
enough for small embedded devices or (most) systems run by a very 
experienced user willing to tinker with his boot process.


s6-rc builds on top of s6 to provide support for state tracking and 
changing on top of s6. It does this in a surprisingly safe, clean and 
simple way. This in turn makes it hard to understand because s6-rc is 
just an empty hull. You still have to write your own start code fitting 
into its structure. The s6 linux init repo contains an example of how it 
could look like.

Re: s6-rc setup

[Laurent Bercot]

On 25/02/2016 15:17, Jan Olszak wrote:

I work on a medium-sized embedded system.


 Depending on the amount of services you are running on that embedded
system, s6-rc might be overpowered for you. Only use it if you have a
nontrivial set of dependencies between services.



So far I've done as little as possible in inittab (syslog, getty, mounts)
+ s6-svscan starts all other stuff.


 You can run your gettys and syslogd under s6 too. :)



s6-svscan doesn't run with PID 1. It's started in inittab.


 This doesn't change anything, s6-rc will work with that setup too.



So can I setup s6-rc + initd and later use s6-linux-init? Would that add
any work compared to doing both at the same time?


 No, those are completely independent steps. However, if you intend
to replace sysvinit at some point, you will need to migrate the services
that are currently supervised by it into services supervised by s6
(and possibly managed by s6-rc).

 The way to setup s6-rc when you have another init is to identify the
points where init launches a one-shot process. sysvinit can launch two:
the "sysinit" one and the "runlevel" one. Once you have successfully
converted your scripts to the s6-rc format, you can run s6-rc-init
in the "sysinit" section, and "s6-rc change my-runlevel" in the
"runlevel" section, for instance.

--
 Laurent

Re: s6-rc setup

[Jan Olszak]

I work on a medium-sized embedded system.
So far I've done as little as possible in inittab (syslog, getty, mounts)
+ s6-svscan starts all other stuff.

s6-svscan doesn't run with PID 1. It's started in inittab.

So can I setup s6-rc + initd and later use s6-linux-init? Would that add
any work compared to doing both at the same time?

Jan


On Thu, Feb 25, 2016 at 2:57 PM, Laurent Bercot  wrote:

> - What's the best approach to setup s6-rc?
>>
>
>  That's... a complex question, because it depends on a lot of parameters.
> What is your context? what is your environment? How have you set up
> your machine so far? etc.
>
>
> - I see this tool http://skarnet.org/software/s6-linux-init/ for init
>> creation. Is this the right direction?
>>
>
>  s6-linux-init is a shortcut to help people run s6-svscan as process 1
> with a catch-all logger: it simply automates the difficult task of
> writing a stage 1 init. It does not write your stage 2 for you -
> which is where s6-rc would get involved.
>
>  You can use s6-linux-init if you wish, but if you have already manually
> done the work of setting up a s6 infrastructure with s6-svscan running
> as process 1, you probably don't need to.
>
>  In order to use s6-rc, what you need to do is 1. analyze your current
> boot process: what services are started, what is a one-shot and what
> spawns a daemon, what are the dependencies between those steps.
> 2. write a set of definition directories, in the s6-rc source format,
> that represents those services and their dependencies. 3. compile that
> set via s6-rc-compile. 4. change your stage 2 init into something akin
> to "s6-rc-init && s6-rc change my-runlevel", if "my-runlevel" is a
> bundle representing all the services you want to have at boot time.
>
> --
>  Laurent
>
>

Re: s6-rc setup

[Laurent Bercot]

- What's the best approach to setup s6-rc?


 That's... a complex question, because it depends on a lot of parameters.
What is your context? what is your environment? How have you set up
your machine so far? etc.



- I see this tool http://skarnet.org/software/s6-linux-init/ for init
creation. Is this the right direction?


 s6-linux-init is a shortcut to help people run s6-svscan as process 1
with a catch-all logger: it simply automates the difficult task of
writing a stage 1 init. It does not write your stage 2 for you -
which is where s6-rc would get involved.

 You can use s6-linux-init if you wish, but if you have already manually
done the work of setting up a s6 infrastructure with s6-svscan running
as process 1, you probably don't need to.

 In order to use s6-rc, what you need to do is 1. analyze your current
boot process: what services are started, what is a one-shot and what
spawns a daemon, what are the dependencies between those steps.
2. write a set of definition directories, in the s6-rc source format,
that represents those services and their dependencies. 3. compile that
set via s6-rc-compile. 4. change your stage 2 init into something akin
to "s6-rc-init && s6-rc change my-runlevel", if "my-runlevel" is a
bundle representing all the services you want to have at boot time.

--
 Laurent