How do I run a service under runit service supervision
How do I create a new service directory
How do I create a new service directory with an appendant log service
How do I tell runit about a new service
How do I start, stop, or restart a service
How can I send signals to a service daemon
How can I query the status of a service
How do I remove a service
How do I make a service depend on another service
What about runlevels
What about LSB init scripts compliance
Is it possible to allow a user other than root to control a service
Does runit support user-specific services?
Does runit work on a read-only filesystem
Answer: Please see the introduction, and web page about runit's benefits.
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.
Answer: runit is free software, it's licensed under a three-clause BSD alike license. See the file package/COPYING in the runit tarball.
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.
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.
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 $
Answer: Create a symbolic link in /var/service/ pointing to the service directory, 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 /var/service/
Answer: Use the sv program. E.g., to restart the socklog-unix service, do:
# sv restart socklog-unix
Answer: Use the sv program. E.g., to send the dhcp service the HUP signal, do:
# sv hup dhcp
Answer: User the sv program. E.g., to query or check the status of the socklog-unix service, do:
# sv status socklog-unixor
# sv check socklog-unix
Answer: Remove the symbolic link in /var/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 /var/service/getty-2
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 $See also the documentation.
Answer: runit supports runlevels, even more flexible than traditional init schemes. See the documentation.
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 #
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/statusThis works similarly with groups, of course.
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/serviceNow floyd can create services on his own, and manage them through symbolic links in ~/service/ to have them run under his user id.
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