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:

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.




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.


# s6-svscan
start on runlevel [2345]
stop on runlevel [!2345]

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

BSD init

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


 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.