supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
* Answers to some GitHub questions
@ 2020-12-26  0:57 Laurent Bercot
  2021-01-06 14:56 ` Alex Efros via supervision
  0 siblings, 1 reply; 4+ messages in thread
From: Laurent Bercot @ 2020-12-26  0:57 UTC (permalink / raw)
  To: supervision


  Hi,

  Someone on GitHub asked a series of questions about s6. I decided to
answer them here, in order to have the post in the ML archives and a
place (outside of GitHub) to refer people to if similar questions arise
in the future.


  * Benefits of s6 over runit?

  s6 has multiple benefits over runit. I'd say that its biggest advantage
is that it is actually maintained and actively developed (albeit more
slowly than I would like). Also, it has been written after runit, so it
learned from it and expanded on it, and considerable effort has been
put into it.

  From a developer's point of view, there is *a lot* that can be said in
favor of s6: technical details that are mostly invisible to the user but
that add up to significantly cleaner code. An example of this is that
s6's supervisor program, s6-supervise, is implemented as a fully
asynchronous state machine, which means it will always be responsive to
user commands no matter what happens; whereas there are situations in
which runsv, runit's supervisor program, will be unresponsive for up to
5 seconds. These details matter.

  From a user's point of view, the most visible difference is that s6
comes with a lot of additional tools that help make it a powerful
toolbox for the admin, in supervision-related matters and beyond. For
instance, s6 keeps a tally of the latest deaths of a process, and allows
you to declare permanent failure on a configurable pattern of deaths.
Or, s6 provides you with an Unix domain super-server that allows you to
quickly write local services, with access control done by uid/gid.

  A comparison between s6 and other supervision suites, including runit,
is available here: https://skarnet.org/software/s6/why.html
  It's an old page, and now very incomplete, but what is written is still
accurate.


  * Why use a database instead of symlinks?

  This question, I think, comes from a misunderstanding. s6 "uses
symlinks" just like every other supervision suite. s6-svscan has a scan
directory, just like runsvdir; s6-supervise has a service directory,
just like runsv. s6 and runit are very similar in that respect.
  Where the database comes into play is when you're using s6-rc, which is
a related, but distinct, piece of software:
  https://skarnet.org/software/s6-rc/

  s6-rc is not a supervision suite, but a service manager that runs *on
top of* the s6 supervision suite. Those are complementary tools. And
yes, s6-rc uses a database (but not a relational one, and no, there is
no SQL backend!), mostly because dependencies between services need to
be stored somewhere. Note that other service managers, like OpenRC or
systemd (the latter being a supervision suite and an init/shutdown
system as well), *also* use a database, they just do not tell you
upfront, and trying to pretend to the user that there's no database
actually makes them more complex and brittle than necessary.


  * Why don't some command-line options have a long form?

  Because s6 is not a GNU package. Long options need the getopt_long(3)
function in order to be parsed; this is a GNU extension to POSIX, and s6
tries to avoid those and stick to POSIX features as much as possible.
  The upcoming high-level interface to s6, s6-frontend, will accept long
options, but it's still in the distant future.


  * You said that the concept of runlevels in runit didn't work in case
of udevd, which had to be run unsupervised in runlevel 1. How does s6
address this problem?

  I certainly did not say that, because runit does not use runlevels,
which are a legacy concept from sysvinit, mixing two completely
different things - halt/reboot procedures (0 and 6) and machine states
(1 to 5, and 1 is a special case requiring particularly ugly hacks).
  But I did say something similar with *stages of init*.

  With the runit model, runsvdir, which starts the supervision tree, is
run in stage 2. Before stage 2, there is no supervision tree available.
And once runsvdir runs, there is no possibility of running oneshots.
So all the oneshots have to be run in stage 1. When a oneshot depends
on a longrun (a daemon), it means that that longrun also has to be run
in stage 1, which prevents it from being supervised since the
supervision tree is not running yet.

  s6 addresses this problem in two ways. Rather, more accurately, it
*does not* address this problem, because it's not for a supervision
system to solve: it's about ordering services, which is the job of a
*service manager*, not a supervision suite. (And that is why runit,
which tries to be a supervision suite and also a /sbin/init and pid 1
but not a service manager, does not solve it.)

  Instead, s6 delegates the problem to other packages that were
specifically written for this:
  - s6-linux-init: https://skarnet.org/software/s6-linux-init/
is an early boot package for Linux, that provides sysvinit
compatibility, and that starts a supervision tree as early as
possible, before running basically *any* service. By using this
package, admins can have a s6-svscan process (the equivalent of
runsvdir) running as pid 1, for the whole lifetime of the system,
before starting their regular boot sequence. This addresses the
problem of not being able to supervise longruns before stage 2: when
using s6-linux-init, you can *always* supervise daemons, no matter
how early they have to be started.
  - s6-rc: the aforementioned service manager. This package handles
dependencies between services, so it can run a complete boot sequence
in the proper order. Longruns are always run supervised, because s6-rc
relies on the existing s6 supervision tree. s6-rc supports oneshots as
well as longruns, so it could run the whole contents of /etc/runit/1 as
oneshots, and start udevd as a longrun at the proper time, so that the
parts of /etc/runit/1 that depend on udevd are only started once udevd
is up and running. (And ready, because s6 supports readiness
notifications, and s6-rc relies on that mechanism to only start a
service when all its dependencies are ready.)

  So, yes, the full picture of how s6 - or rather, the s6 ecosystem -
does it is more complex, because the problem to address is not a
trivial one and involves more than just process supervision. But when
you have s6-linux-init + s6 + s6-rc, you have a complete init system,
that can accommodate any kind of service ordering you need, without
exceptions, hacks or adhocness.


  * Why is there no man documentation for s6 and its related binaries?

  Because you have not looked carefully enough. :) There *are* s6 man
pages now, thanks to flexibeast:
  https://github.com/flexibeast/s6-man-pages
and they are linked from the s6 main page.

  Now if the question is: why aren't the man pages bundled in the s6
package? then it's a rather complex answer that involves the very sorry
state of rich text format processing tools, and my potent dislike for
the roff/mandoc/... format and for anything related to documentation
formats in general as well as afferent discussions. My position about
the whole thing is summed up here:
https://skarnet.org/cgi-bin/archive.cgi?2:mss:2583:202008:liednclklokjhnokhdhg
and the bottom hard line is that until a miracle happens and it becomes
simple to write documentation in a clear, humanly understandable format
that compiles easily to both mandoc and clean, acceptable HTML and does
not require the user to install bloated toolchains written in a language
that pulls two kitchen sinks of dependencies, if you need s6 man pages,
the ones maintained by flexibeast are where it's at.


  * Did Gerrit Pape abandon runit? Has development stopped?

  That's not a question for me to answer. But what I know is that
runit is not *actively* developed by Gerrit anymore, even if he pops
here from time to time and has not formally abandoned the project.
  What he said about it in 2016:
https://skarnet.org/cgi-bin/archive.cgi?2:mss:1417:lodleppmpcafcpjcgidf
  All of Gerrit's interventions on the supervision mailing-list:
https://www.mail-archive.com/search?a=1&l=supervision%40list.skarnet.org&haswords=&x=12&y=18&from=Gerrit+Pape&subject=&datewithin=1d&date=&notwords=&o=newest

--
  Laurent


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Answers to some GitHub questions
  2020-12-26  0:57 Answers to some GitHub questions Laurent Bercot
@ 2021-01-06 14:56 ` Alex Efros via supervision
  2021-01-06 18:47   ` Colin Booth
  2021-01-09 17:25   ` Laurent Bercot
  0 siblings, 2 replies; 4+ messages in thread
From: Alex Efros via supervision @ 2021-01-06 14:56 UTC (permalink / raw)
  To: supervision

Hi!

Thanks, this was useful reading.

Is there a migration guide from runit to s6?

If not, it might be useful to create one with hints how to rewrite
/etc/runit/{1,3} and runit services in s6-way, what to run instead of
/sbin/runit-init as kernel's init= param, and what to use instead of
`runit-init {0,6}` to halt/reboot. Because, you know, while everything
you've said about runit vs s6 is true, runit is still "just works"… so
without easy-to-follow guide it's hard to find a motivation to move to s6.

-- 
			WBR, Alex.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Answers to some GitHub questions
  2021-01-06 14:56 ` Alex Efros via supervision
@ 2021-01-06 18:47   ` Colin Booth
  2021-01-09 17:25   ` Laurent Bercot
  1 sibling, 0 replies; 4+ messages in thread
From: Colin Booth @ 2021-01-06 18:47 UTC (permalink / raw)
  To: supervision

On Wed, Jan 06, 2021 at 04:56:29PM +0200, Alex Efros via supervision wrote:
> Hi!
> 
> Thanks, this was useful reading.
> 
> Is there a migration guide from runit to s6?
> 
> If not, it might be useful to create one with hints how to rewrite
> /etc/runit/{1,3} and runit services in s6-way, what to run instead of
> /sbin/runit-init as kernel's init= param, and what to use instead of
> `runit-init {0,6}` to halt/reboot. Because, you know, while everything
> you've said about runit vs s6 is true, runit is still "just works"… so
> without easy-to-follow guide it's hard to find a motivation to move to s6.
> 
> -- 
> 			WBR, Alex.
I'm working on one actually. I wrote up a how-to/what I did for Void
Linux here:
https://www.reddit.com/r/voidlinux/comments/khn1jy/adventures_in_booting_void_on_s6/

and will be writing a part two in the next few weeks (free time and life
have been getting in the way). 

Part 1 is a "light touch" conversion, it has some shims to get
everything working right but for the most part it's still pretty
runit-based. Part 2 will be a heavier set of changes and will leverage
s6-rc, some run script generators that I've written, and a few other
things to try and make everything work nicer (better backwards
compatibility with the distro packages, better support for the s6
notification framework, and so on).

My long-term (maybe medium term) goal is to get this into a shape where
it is acceptable in the void package mainline as an alternate base
system, get it in there, and then hand off maintainership to someone who
is more central to Void. Longest term is obvious - adjust the part 2 stuff
so that it's acceptable as the default, but that is a long way off and
this is an iterative process.

-- 
Colin Booth

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Answers to some GitHub questions
  2021-01-06 14:56 ` Alex Efros via supervision
  2021-01-06 18:47   ` Colin Booth
@ 2021-01-09 17:25   ` Laurent Bercot
  1 sibling, 0 replies; 4+ messages in thread
From: Laurent Bercot @ 2021-01-09 17:25 UTC (permalink / raw)
  To: Alex Efros, supervision

>Is there a migration guide from runit to s6?

  I added a very basic list of things to do as a FAQ in
  https://skarnet.org/software/s6-linux-init/quickstart.html

  Please comment if there are things that need change or clarification.
(The prose is bad, I know; please stick to content suggestions.)
I linked to Colin's post, with his permission, for a more in-depth
explanation.

--
  Laurent


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-01-09 17:25 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-26  0:57 Answers to some GitHub questions Laurent Bercot
2021-01-06 14:56 ` Alex Efros via supervision
2021-01-06 18:47   ` Colin Booth
2021-01-09 17:25   ` Laurent Bercot

supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/supervision

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 supervision supervision/ http://inbox.vuxu.org/supervision \
		subscribe@list.skarnet.org
	public-inbox-index supervision

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.supervision.general


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git