From 65270743f03969ac36ab65db2b4879da0445b8e1 Mon Sep 17 00:00:00 2001
From: Laurent Bercot
Date: Sat, 9 Jan 2021 09:12:14 +0000
Subject: Add a runit conversion FAQ to quickstart
---
doc/quickstart.html | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 98 insertions(+), 1 deletion(-)
(limited to 'doc/quickstart.html')
diff --git a/doc/quickstart.html b/doc/quickstart.html
index 253429f..3fb2d19 100644
--- a/doc/quickstart.html
+++ b/doc/quickstart.html
@@ -16,7 +16,7 @@
skarnet.org
- Quickstart for s6-linux-init
+ Quickstart and FAQ for s6-linux-init
Quickstart
@@ -49,5 +49,102 @@ your old init system and need to use a reboot command that matches it.
/sbin/poweroff or /sbin/reboot as usual.
+ FAQ
+
+ How do I convert a runit setup to a s6 one ?
+
+
+ A runit and a s6 setup are very similar. There are just three things you
+need to pay attention to:
+
+
+
+ - runsv supports
+customized controls, whereas
+s6-supervise does
+not. Fortunately, very few services use the customized control feature of
+runit; and s6 supports customizing the termination signal to a process via the
+down-signal file,
+which can replace 99% of the legit uses of customized control. So, you should
+check your service directories for control/ subdirectories, and
+adapt them depending on how your service handles controls. If a service does
+not use customized controls, you don't need to make any change and the service
+will run under s6-supervise as is.
+ - The interface of svlogd,
+runit's logger, is different from the interface of
+s6-log, s6's logger.
+Namely, svlogd reads a config file in its log directory, while s6-log reads its
+configuration on its command line. If you have logging services that use svlogd,
+you should read their configuration in their logdir, and translate it to the
+proper s6-log invocation.
+ - And, finally, the init process. Understanding how s6-linux-init works may
+seem daunting, but using it really is a lot simpler than it looks.
+
+
+
+ In a runit setup, you have
+the runit program running as
+pid 1, and sequentially spawning /etc/runit/1, then /etc/runit/2
+which contains the invocation of
+runsvdir, and finally
+/etc/runit/3 at shutdown time when runsvdir is dead.
+
+
+
+ In a s6 setup that you have booted via
+s6-linux-init, the scanner,
+s6-svscan (the equivalent
+of runsvdir), runs as
+pid 1, very early, and remains there for the whole lifetime of the machine. At
+boot time, the /etc/s6-linux-init/current/scripts/rc.init script is run, with
+the supervision tree already in place; when it exits, the system is supposed to
+be in a fully-booted, stable state. At shutdown time (on receipt of a shutdown
+command), the /etc/s6-linux-init/current/scripts/rc.shutdown script is run,
+with the supervision tree still in place; when it exits, the
+filesystems will be unmounted and the machine will be rebooted and/or stopped.
+
+
+
+ So, the quickest way to port a runit setup to a s6-linux-init one is to:
+
+
+
+ - Copy your /etc/runit/1 to /etc/s6-linux-init/current/scripts/rc.init.
+The only thing you should remove here is the creation of /run, because s6-linux-init
+has already mounted a tmpfs on /run. But basically all the rest should stay.
+ - Also copy the parts of /etc/runit/2, if any, that come before the
+runsvdir invocation, to
+/etc/s6-linux-init/current/scripts/rc.init.
+ - At the end of /etc/s6-linux-init/current/scripts/rc.init, symlink all
+your runit service directories to /run/service, and call
+s6-svscanctl -a /run/service. This will start and supervise all the services
+that you have symlinked, the way the original runsvdir invocation would have.
+ - Copy your /etc/runit/3 to /etc/s6-linux-init/current/scripts/rc.shutdown,
+removing the parts that unmount the filesystems and reboot the machine.
+
+
+
+ Once you have done that, you have a literal translation of your runit system into a
+s6 system, and it should boot, and work, albeit in a non-idiomatic, unoptimized way.
+Further work to make it prettier can include:
+
+
+
+ - Identifying daemons you run in /etc/s6-linux-init/current/scripts/rc.init
+and making them early services instead.
+ - Or, more idiomatically, analyze your whole boot sequence in
+/etc/s6-linux-init/current/scripts/rc.init and the daemons in your runit
+service directories, and convert the boot sequence so it can be handled by a service manager,
+for instance s6-rc.
+
+
+
+ Colin Booth has a
+series
+of posts on Reddit that go into more detail on how to use a Void Linux distribution,
+which natively uses runit, with the s6 ecosystem instead; there are step-by-step tutorials
+as well as turnkey solutions, and it is recommended reading even if you do not use Void.
+
+