Using runit for your services

The runit services supervisor is positioned as a replacement for standard Unix initialization scripts.

But in practice, it turned out that runit is ideal for managing services, regardless of initialization, etc.

Introduction

The supervisor takes on such functionality as:

• turning any process into a demon;
• logging process output and logging;
• start, stop, restart, status request, control scripts for init.d;
• shutting down and launching services automatically when new services appear in the list or remove old ones from the list;
• the ability to maintain several independent lists of services at the same time (for example, for each user separately and for the system as a whole);
• convenient API for service management.

For most operating systems, runit is already included in the package repositories (apt-get install runit). In addition, we have a ready-made set of recipes for popular services (nginx, apache, etc.).
')
Next, consider the standard runit scheme (which is used by default):

Demonization

Each service is described by a separate / etc / sv / <service name> directory.

usually it is enough to have an executable run script in this directory

#!/bin/bash exec 2>&1 exec your_running_command 

It is important that your_running_command does not demonize itself (it does not disconnect from the standard stdin, stdout, stderr streams).

Redirecting errors to standard output is needed for logging. Logging is performed if the / etc / sv / <service name> / log / directory contains the run file

 #!/bin/bash LOG_FOLDER=/var/log/< > mkdir -p $LOG_FOLDER exec svlogd -tt $LOG_FOLDER 

Services located in the / etc / sv / directory are not executed until they are located in the / etc / service / directory.

As soon as you make ln -s /etc/sv/< > /etc/service/< > , the service runsvdir will see the new service, and start it. Moreover, in case of stopping the service, it will be automatically restarted. This gives a much faster response to stopping the service compared to using monitoring services (god or monit).

Logging logs

When using svlogd logs are placed in the folder that you specified when it was launched. In this case, the current log is in the current file, and periodically rooting logs in this folder.

Control

You can sv (start|stop|restart...) < > , stop, restart services using the sv (start|stop|restart...) < > command sv (start|stop|restart...) < > .

In addition, when you start the service, the / etc / service / <service name> / supervise directory will appear, in which very useful files and streams will be located:

• pid is the Unix process id;
• stat - human-readable service status
• status - the machine-readable state of the process
• control - control flow
• and so on...

It can be noted that to stop or start the process, it is enough to open the control stream for recording, and send the d character (from down) or u (from up) there, respectively.

In the style of init.d

There is nothing easier than maintaining control in the style of init.d.

Just do ln -s /usr/bin/sv /etc/init.d/< > . sv will understand that it was called in the init.d style, and will be ready to accept commands like /etc/init.d/< > start name /etc/init.d/< > start etc. Quite a bit of magic, right?

Setting up services

The runit utility comes bundled with the chpst utility, which allows you to perform services with additional configuration (limit the memory size, run from under a specific user, with a different nice level, etc.).

Summary

runit turned out to be so convenient and reliable for organizing our services that we try to translate all our demons under runit, at the same time refusing various hemorrhoids in the form of demonization packages a la daemons gem. Also on parts of the machines we got rid of Monit (where only monitoring of processes was required).

I highly recommend reading the comment from the powerman , as well as the article about the web-interface to runit .