From 90b12bd71bb9fc79a4640b9112c13ef529d0196a Mon Sep 17 00:00:00 2001 From: Laurent Bercot Date: Fri, 5 Dec 2014 22:26:11 +0000 Subject: Initial commit --- doc/s6-svscan-not-1.html | 140 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 140 insertions(+) create mode 100644 doc/s6-svscan-not-1.html (limited to 'doc/s6-svscan-not-1.html') diff --git a/doc/s6-svscan-not-1.html b/doc/s6-svscan-not-1.html new file mode 100644 index 0000000..613ba3d --- /dev/null +++ b/doc/s6-svscan-not-1.html @@ -0,0 +1,140 @@ + + + + + s6: How to run s6-svscan under another init process + + + + + + +

+s6
+Software
+skarnet.org +

+ +

How to run s6-svscan under another init process

+ +

+ You can have a reliable supervision tree even if s6-svscan is not your process 1. +The supervision tree just has to be rooted in process 1: that means that +your process 1 will have to supervise your s6-svscan process somehow. That way, +if s6-svscan dies, it will be restarted, and your set of services will always +be maintained. +

+ +

+ Be aware, though, that pipes between services and loggers are maintained +by the s6-svscan process; if this process dies, the pipes will be closed and +some logs may be lost. +

+ + +

Logging the supervision tree's output

+ + +

+ s6-svscan and the various s6-supervise processes might produce error or +warning messages; those messages are written to s6-svscan's stderr (which +is inherited by the s6-supervise processes). To log these messages: +

+ +

You can use your init system's logging tools, and make your init +system launch s6-svscan as is; its stderr should already be taken care +of by the logging tools.
You can use a trick similar to the process +1 output logging trick so the supervision tree's messages are logged via +a service that's maintained by the supervision tree itself. Then your init +system should not launch s6-svscan directly, but a wrapper script that performs +the proper redirections. The +examples/s6-svscanboot file in the s6 distribution gives an example of +such a script. Make sure that your initial scan +directory contains a service directory for your +initial logging service, that must read on the logging FIFO.

+ +

+ In the following examples, we'll assume that /command/s6-svscanboot +is the name of the script you are using to start s6-svscan. Adjust this accordingly. +

+ + +

System V init

+ + +

+ Put an appropriate line in your /etc/inittab file, then reload this +config file with telinit q. +

+ +

Example

+ +

 SV:123456:respawn:/command/s6-svscanboot

+ + + +

Upstart

+ + +

+ Put an appropriate configuration file in the /etc/init folder, +for instance /etc/init/s6-svscan.conf, then start the service +with start s6-svscan. +

+ +

Example

+ +

# s6-svscan
+start on runlevel [2345]
+stop on runlevel [!2345]
+
+oom never
+respawn
+exec /command/s6-svscanboot
+

+ + +

systemd

+ +

+ systemd has +its +own way of supervising services. If you are a systemd user, chances +are you do not need s6. If you are interested in using s6, I encourage +you to also stop using systemd. +

+ +

+ + +

BSD init

+ + +

+ Put an appropriate line in your /etc/ttys file, then reload this +file with kill -s HUP 1. +

+ +

Example

+ +

 sv /command/s6-svscanboot "" on

+ + +

MacOS X launchd

+ + +

+ Like systemd, launchd comes with its own +way +of supervising services; if you are a launchd user, you probably do +not need s6. +

+ + + + -- cgit v1.2.3