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

See also the comment about systemd below, that applies to Upstart to some extent.


Do yourself and the community a favor and stop using systemd. Every piece of init software that goes for more instead of less, and that pretends to be suitable for embedded environments, doesn't even deserve a look. Upstart and launchd suffer from extreme featuritis too, but at least they don't claim to run on embedded platforms.

Not convinced? I really have to write a page that exposes the horrors of D-Bus. Then any sane person who knows a bit of Unix will understand how incredibly wrong it is to link process 1 against D-Bus. The primary author of systemd says D-Bus is only used "as IPC to control the init system"; maybe, but it's still wrong, and to control the init system, a single FIFO does the job. You tend to miss those details when you spend more time advertising your project than designing it.

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

I'm not knowledgeable about MacOS X details. If someone wants to provide information on how to start a s6-svscan-based supervision tree under launchd, I'll be happy to complete this documentation in a future release of s6.