The runsv program supervises the corresponding service daemon. By default a service is defined to be up, that means, if the service daemon dies, it will be restarted. Of course you can tell runsv otherwise.
You don't have such a control interface with sysv init for example. Using the control interface to send signals to the service daemon saves a lot of extra (non trivial) work to reliably find out the daemon's process id. Also sysv init only supports 'respawning' of services started from inittab.
You don't necessarily have that with sysv init scripts for example. It requires a carefully written init script that reliably cleans up and sets the initial process state before starting the service daemon. This adds even more complexity to the init script in comparison with a run script used by runit. Many of today's init scripts don't provide a clean process state, here is an example on what could happen:
# /etc/init.d/foo-daemon start Starting foo daemon: food. #Fine. Everything works, nothing to worry about. After rebooting the system this shows up on the screen:
... Starting foo daemon: food: command not found failed. ...The food program is installed in /opt/foo/bin/. When starting the service for the first time using the init script, the PATH environment variable contained /opt/foo/bin. After reboot init started the service using the init script, but with a different value for the PATH variable, not containing /opt/foo/bin. Of course the init script should have set PATH before starting the daemon; the problem is that it worked in the first place, and that the error didn't show up until system reboot.
With bad init scripts miraculous things could also happen when just doing
# /etc/init.d/foo-daemon restartat the command line.
The service daemon and the log daemon can run with different process states, and under different user id's. runit supports easy and reliable logging for service daemons running chroot'ed.
If runsv is told to shutdown a service, e.g. at system shutdown, it ensures that the log service stays up as long as the corresponding service daemon is running and possibly writing to the log.
On system shutdown, stage 3 uses runsv's control interface to wait until each service daemon is terminated and all logs are written. Again, services are taken down in parallel. As soon as all services are done, system halt or system reboot is initiated.
Stages 1 and 3 handle one time tasks. They only run for short and exit soon. Stage 2 handles the system's uptime tasks (via the runsvdir program) and is running the whole system's uptime.
runit's stage 2 is portable across UNIX systems. runit is well suited for server systems and embedded systems, and also does its job well on desktop systems.
Stage 2 already is packaging friendly: all a software package that provides a service needs to do is to include a service directory in the package and to provide a symbolic link to this directory in /var/service/. The service will be started within five seconds. The package's install and update scripts can use the reliable control interface to stop, start, restart, or send signals to the service. On package removal, the symbolic link simply is removed.
The runit programs have a very small memory footprint and do not allocate memory dynamically.