Instalar runsv

Wikijc:Sistemas runsv

Instalar runsv

¿Cansado de procesos PID, que requieren acceso de root, y scripts de inicio sólo para que las aplicaciones arranquen cuando su servidor inicia? ¿Querés una alternativa mejor que también va a reiniciar los servicios en caso de que accidente? Si es así, entonces lee esta introducción al proceso de supervisión con runit / daemontools.
Primero instalamos los siguientes paquetes
$sudo apt-get install runit runit-run socklog socklog-run
[sudo] password for sysadmin:
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Paquetes recomendados
fgetty ipsvd
Los siguientes paquetes se ELIMINARÁN:
klogd sysklogd ubuntu-minimal
Se instalarán los siguientes paquetes NUEVOS:
runit runit-run socklog socklog-run
0 actualizados, 4 se instalarán, 3 para eliminar y 49 no actualizados.
After this operation, 737kB of additional disk space will be used.
¿Desea continuar [S/n]? s
Des:1 http://es.archive.ubuntu.com hardy/universe runit 1.8.0-5ubuntu2 [110kB]
Des:2 http://es.archive.ubuntu.com hardy/universe runit-run 0.8.1 [10,9kB]
Des:3 http://es.archive.ubuntu.com hardy/universe socklog 2.1.0-7 [56,4kB]
Des:4 http://es.archive.ubuntu.com hardy/universe socklog-run 2.1.0-7 [13,1kB]
Descargados 190kB en 1s (160kB/s)
(Leyendo la base de datos ...
16868 ficheros y directorios instalados actualmente.)
Desinstalando ubuntu-minimal ...
Desinstalando klogd ...

• Stopping kernel log daemon... [ OK ]

Desinstalando sysklogd ...

• Stopping system log daemon... [ OK ]

Seleccionando el paquete runit previamente no seleccionado.
(Leyendo la base de datos ...
16842 ficheros y directorios instalados actualmente.)
Desempaquetando runit (de .../runit_1.8.0-5ubuntu2_i386.deb) ...
Seleccionando el paquete runit-run previamente no seleccionado.
Desempaquetando runit-run (de .../runit-run_0.8.1_all.deb) ...

This package diverts sysvinit's /sbin/init binary. Use

1. /sbin/init.sysv 6

to reboot the system with runit as process no 1 after installing this
package.

Please read the runit documentation before proceeding:

http://smarden.org/runit/

Press ENTER to continue, press Ctrl-C to abort...

Añadiendo `diversion of /sbin/init to /sbin/init.sysv by runit-run'
Añadiendo `diversion of /usr/share/man/man8/init.8.gz to /usr/share/man/man8/init.sysv.8.gz by runit-run'
Seleccionando el paquete socklog previamente no seleccionado.
Desempaquetando socklog (de .../socklog_2.1.0-7_i386.deb) ...
Seleccionando el paquete socklog-run previamente no seleccionado.
Desempaquetando socklog-run (de .../socklog-run_2.1.0-7_all.deb) ...
Configurando runit (1.8.0-5ubuntu2) ...

Configurando runit-run (0.8.1) ...

Configurando socklog (2.1.0-7) ...
Warning: The home dir /nonexistent you specified can't be accessed: No such file or directory
Adding system user `log' (UID 106) ...
Adding new user `log' (UID 106) with group `nogroup' ...
Not creating home directory `/nonexistent'.

Configurando socklog-run (2.1.0-7) ...


Los scripts de inicio clasicos, por ejemplo, /etc/init.d/apache, son ampliamente utilizados para iniciar los procesos de arranque del sistema, cuando son ejecutados por 'init'. Lamentablemente, los scripts de inicio son engorrosos y propensos a errores al escribir, deben normalmente ser editados, ejecutados como root, y ademas los procesos de no se reinician automáticamente en caso de accidente

Una alternativa son los llamados procesos de supervisión, cada proceso esta al cuidado de la supervisión de un pequeño proceso, que trata de arrancarlo cuando este se cierra inesperadamente. Los procesos de supervisión estan a su vez a supervisados por otros procesos, en una jerarquía que se extiende hasta el "maestro" UNIX proceso con PID 1, por lo general "init".

(El proceso de supervisión es patrón establecido hace mucho tiempo, e incluso está incorporada en el lenguaje de programación Erlang, que se utiliza para ultra-fiables aplicaciones de telecomunicaciones.)

Es posible sustituir todos los scripts de inicio con los procesos de supervisión, pero no es necesario. Podemos obtener la mayor parte de los beneficios simplemente utilizando procesos de supervisión para ejecutar nuestras aplicaciones, dejando los scripts de inicio en lugar de servicios del sistema

Runit es una licencia más cómoda y activa implantada de las daemontools, escrito por Gerrit Pape.

Hay sólo dos programas clave en runit. En primer lugar, runsv supervisa el proceso de un servicio individual y runsvdir programa que supervisa el directorio donde los servicios estan ejecutando un hijo de los procesos. Por ejemplo, un caso runsvdirsupervisa los servicios en los subdirectorios de /var/servicio/.
Vamos a crear un servicio simple como root ahora:

$ mkdir /etc/runit/sleeper

Ahora cremos un script de arranque para el servicio; run scripts should not fork, exit or maintain their own PID files. We'll use a 5-minute "sleep" command to simulate a long-running service that occasionally crashes. We create /etc/runit/sleeper/run as follows:

1. !/bin/sh -e

exec 2>&1
exec /etc/init.d/vsftpd start

Ponemos los permisos del fichero creado como ejecutable:
$ chmod +x /etc/runit/sleeper/run

Recordemos que runsvdir esta actualmente apuntando a /var/service/ -- Tenemos que apuntar nuestro servicio a esta ruta con un enlace:
$ ln -s /etc/runit/vsftpd /var/service/vsftpd

Con pstree vemos el resultado:

init─┬─atd

    ├─bash
    ├─cron
    ├─6*[getty]
    ├─rc───sh
    ├─shutdown
    ├─sshd───sshd───sshd───bash───pstree
    ├─udevd
    └─vsftpd

runsvdir notifica el nuevo servicio y lo ejecuta como runsv.

Para parar y arrancar el servicio y ver el estado, usamos el comando 'sv':
$ sv status vsftpd
run: sleeper: (pid 32493) 147s
$ sv stop vsftpd
ok: down: vsftpd: 1s, normally up
$ sv status vsftpd
down: vsftpd: 4s, normally up

Si el servicio se cierra por algun error inexperado, runsv lo reinicia automaticamente en unos segundos:
$ killall vsftpd
Nuestro servicio vsftpd' se inicia con runsvdir cuando nuestro sistema operativo arranca (runsvdir esta supervisado por - init.)
Si eliminamos el enlace simbólico a vsftpd de /var/servicio/, entonces el proceso vsftpd será detenido y retirado de la supervisión de árboles.
¿Por qué el enlace?

Mantener nuestro servicio de definiciones en un directorio /etc/runit/ nos permite iniciar manualmente con el fin de depurar nuestros scripts, antes de poner los servicios bajo el control de runit mediante la adición de enlaces simbólicos en/var/servicio.
Servicios fiables para usuarios sin privilegios
Podemos hacer que no sea root quien supervise los servicios. Podemos simplemente dar a nuestra aplicación el usuario (login 'appuser') a ~/servicio de directorio y, a continuación, configurar un servicio en /var/servicio que va a funcionar con fiabilidad con los privilegios del appuser:

$ mkdir /etc/service/appuser

ejecutamos el script con el usuario que queramos:
!/bin/sh -e
exec 2>&1
exec chpst -u appuser runsvdir /home/appuser/service

Ahora appuser puede crear o hacer un link simbolicosobre ~appuser/service, y puede ser manejado de manera fiable
Tenga en cuenta que appuser debe pasar la ruta completa a sus servicios cuando el control de ellos usando sv, ya que asume sv otros nombres de servicios que corresponden a servicios de directorios en / var / servicio:
% sv restart ~/service/myapplication

Ejemplo de como corren 3 aplicaciones: The following is an example process tree on a server running three applications, each as its own user with a ~/service directory:

init-+-atd

    |-lighttpd

 .......

    |-postgres---11*[postgres]

    |-runsvdir-+-runsv---runsvdir-+-2*[runsv---ruby---{ruby}]

    |          |                  |-3*[runsv---mongrel_rails---{mongrel_rails}]

    |          |                  `-runsv---pen

    |          |-runsv---runsvdir-+-runsv---ruby---{ruby}

    |          |                  |-5*[runsv---mongrel_rails---{mongrel_rails}]

    |          |                  `-runsv---pen

    |          `-runsv---runsvdir-+-runsv---mongrel_rails---{mongrel_rails}

    |                             `-runsv---pen

    `-sshd

Debugging service definitions

If runsvdir is unable to execute a 'run' script for some reason, then by default it will write log messages to its process title: look at the output of 'ps aux' for a clue (this is the reason for the long '......' line above). If possible, try starting your run script by hand before symlinking the service directory into the location runsvdir is watching.
Other capabilities

Runit can do much more than I have presented here; it can manage reliable logging of stdout/stderr output as an alternative to (or in addition to) syslog; take a look at svlogd. Setting up logging can make it much easier to figure out why services don't seem to be starting correctly.

Simple mechanisms also exist for specifying dependencies between services, such that one will not start before another is up and running. That's typically less an issue for application administrators than it is for system administrators.
Under the covers

The design of runit is full of elegant touches; for example, runsv creates a 'supervision' subdirectory of the service directory it is supervising. In that directory it writes a PID file and a named pipe connected to itself. 'sv' then simply writes rudimentary commands to the pipe, to which runsv then reacts.

Monitoring tools such as monit can be easily configured to report on the status of service processes by pointing them at the PID files.
Unprivileged processes, privileged ports

Sometimes people run applications as root simply because they need to listen on privileged ports (ie. ports below 1024). If you need such a port, you can still run your application as an unprivileged service; consider using iptables or a tcp proxy like pen to proxy that port through to your unprivileged runit services listening on unprivileged ports.
More

If you found this article helpful, or want to read my forthcoming article about reliably running Ruby on Rails applications using runit, please subscribe to my feed.