s6: How to run s6-svscan under another init process
Description: s6: s6-svscan as not-init
Keywords: s6 supervision svscan s6-svscan init process boot

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 some of the following examples, we'll assume that `/command/s6-svscanboot` is the name of the script you are using to start s6-svscan. We will also assume that all of the s6 executables are available through the `/command` path. 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

Put an appropriate unit file in the `/etc/systemd/system` folder, for instance `/etc/systemd/system/s6.service`. It will be picked up by systemd at boot time.

### Example

    [Unit]
    Description=s6 supervision tree
    Documentation=https://skarnet.org/software/s6/

    [Install]
    WantedBy=multi-user.target

    [Service]
    Type=simple
    ExecStart=/command/s6-svscan /run/service
    ExecReload=/command/s6-svscanctl -an /run/service
    Restart=always
    RestartSec=1
    KillMode=mixed

Please note that, among other things, systemd performs process supervision, so depending on the level of integration with your distribution that you wish to achieve, you may be better off using systemd to directly manage your daemons. Please also note that systemd is a terrible piece of software engineering, and if at all possible, you should try and switch to a distribution that does not use it.

## 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 launchd

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