Frequently Asked Questions

What is this runit "init scheme" about? Why is it that different from sysvinit and other init schemes?

Answer: Please read the introduction in the sources or refer to the home page on the wiki to find this out.

I have a question, runit is doing something wrong, or I'm doing something wrong, what should I do?

Answer: First see the documentation, especially this list of frequently asked questions, and the man pages if you have a question about a specific runit program. If that still doesn't answer your question, try to search the supervision mailing list archive. Finally, if this fails, feel free to post your question to the supervision mailing list. What's the license, is runit free software

I would like to distribute runit, in source and binary form. Am I allowed to do so?

Answer: runit is free software, it's licensed under a three-clause BSD alike license. See the file package/COPYING in the runit tarball. If you fully abide by the licensing terms therein, yes, you may do so.

How do I run a service under runit service supervision?

I want a service to be run under runit service supervision, so that it's automatically started on system boot, and supervised while system uptime. How does that work?

Answer: runit doesn't use the usual /etc/init.d/ init script interface, but uses a directory per service. To integrate a service into the runit init scheme, create a service directory for the service, and tell runit about it by symlinking the service directory into the desired runlevel's controls directory (e.g. /etc/runit/runsvdir/default)

How do I create a new service directory for the use with runit?

Answer: Service directories usually are placed into the /etc/sv/ directory. Create a new directory for your service in /etc/sv/, put a ./run script into it, and make the script executable. Note that for the use with runit, service daemons must not put themself into the background, but must run in the foreground. Here's a simple example for a getty service:

$ cat /etc/sv/getty-2/run
#!/bin/sh
exec getty 38400 tty2 linux
$

Note the exec in the last line, it tells the shell that interprets the script to replace itself with the service daemon getty; this is necessary to make controlling the service work properly.

How do I create a service directory with an appendant log service for the use with runit?

Answer: First create the service directory for the service. Then create a subdirectory ./log in the service directory, again put a ./run script into it, and make the script executable. The ./run script must run a service logging daemon, normally this is the svlogd program. See the runsv man page for details. Here's an example of a ./log/run script:

$ cat /etc/sv/socklog-klog/log/run
#!/bin/sh
exec chpst -ulog svlogd -tt ./main
$

How do I tell runit about a new service?

I created a service directory for a service that should run under runit service supervision. How do I tell runit about the new service directory, so that it picks up and runs the service by default?

Answer: Create a symbolic link in /etc/runit/runsvdir/current or /service directory pointing to the service directory you want to be added to supervision, runit will pick up the service within the next five seconds, and automatically start it on system boot. E.g.:

# ln -s /etc/sv/getty-2 /etc/runit/runsvdir/current

How do I start, stop, or restart a service?

I want to stop a service temporarily, and probably restart is later, or I want to have it restarted immediately. How can I control a service running under runit service supervision?

Answer: Use the sv program. E.g., to restart the socklog-unix service, do:

# sv restart socklog-unix

How can I send signals to a service daemon?

I want to send a service daemon the HUP signal, to have it re-read its configuration, or I want to send it the INT signal. How do you do this with runit?

Answer: Use the sv program. E.g., to send the dhcp service the HUP signal, do:

# sv hup dhcp

How can I query the status of a service

I want to now the status of a service, whether it is up and available, or down as requested, or so. How can I find out this information?

Answer: User the sv program. E.g., to query or check the status of the socklog-unix service, do:

# sv status socklog-unix

or

# sv check socklog-unix

How do I remove a service?

I want to remove a service that currently runs under runit service supervision. How do I tell runit this?

Answer: Remove the symbolic link in /service/ pointing to the service directory, runit recognizes the removed service within the next five seconds, then stops the service, the optional log service, and finally the supervisor process. E.g.:

# rm /service/getty-2

How do I make a service depend on another service

I have a service that needs another service to be available before it can start. How can I tell runit about this dependency?

Answer: Make sure in the ./run script of the dependant service that the service it depends on is available before the service daemon starts. The sv program can be used for that. E.g. the cron service wants the socklog-unix system logging service to be available before starting the cron service daemon, so no logs get lost:

$ cat /etc/sv/cron/run

#!/bin/sh
sv start socklog-unix || exit 1
exec cron -f
$

Check the documentation for more details. There's a lot of sophistication possible with this.

What about runlevels?

Other init schemes support runlevels, what about runit?

Answer: runit supports runlevels, even more flexible than traditional init schemes. See the documentation for more details.

What about LSB init scripts compliance

I know about the sv program to control a service, but have applications that rely on the /etc/init.d/ scripts interface as defined through LSB. Do I need to change the application to work with runit?

Answer: You don't need to change the application. The sv program supports the /etc/init.d/ script interface as defined through LSB. To make this script interface work for a service, create a symbolic link in /etc/init.d/, named as the service daemon, pointing to the sv program, e.g. for the cron service:

# ln -s /bin/sv /etc/init.d/cron
# /etc/init.d/cron restart
ok: run: cron: (pid 5869) 0s
#

Is it possible to allow a user other than root to control a service?

Using the sv program to control a service, or query its status informations, only works as root. Is it possible to allow non-root users to control a service too?

Answer: Yes, you simply need to adjust file system permissions for the ./supervise/ subdirectory in the service directory. E.g.: to allow the user burdon to control the service dhcp, change to the dhcp service directory, and do

# chmod 755 ./supervise
# chown burdon ./supervise/ok ./supervise/control ./supervise/status

This works similarly with groups, of course.

Does runit support user-specific services?

It's very nice to simply create symbolic links to add system-wide services. Does this work for user-specific services too?

Answer: Yes. E.g.: to provide the user floyd with facility to manage services through ~/service/, create a service runsvdir-floyd with the following run script and a usual log/run script, and tell runit about the service

#!/bin/sh
exec 2>&1
exec chpst -ufloyd runsvdir /home/floyd/service

Now floyd can create services on his own, and manage them through symbolic links in ~/service/ to have them run under his user id.

Does runit work on a read-only filesystem?

On some systems /etc/ is mounted read-only by default. runit uses many files in /etc/ it needs to write to, like /etc/runit/stopit, and the ./supervise/ subdirectories in the service directories. How can I make runit work on my system?

Answer: Use symbolic links, runit deals with them well, even with dangling symlinks. E.g., make a ramdisk available at a moint point, say /var/run/, and create symbolic links for the files and directories that runit needs to write access to pointing into /var/run/:

# ln -s /var/run/runit.stopit /etc/runit/stopit
# ln -s /var/run/sv.getty-2 /etc/sv/getty-2/supervise