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.

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.

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

Example

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

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 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.

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

Example

 sv /command/s6-svscanboot "" on 

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