4.1. Gestión de servicios

Se trató bajo un epígrafe anterior cómo gestionar de manera básica los procesos del sistema, en concreto, cómo conocer los que se ejecutan y cómo pararlos de manera más o menos expeditiva. Para un sistema de escritorio muy básico, estos conocimientos son suficientes, y, aunque en todo sistema corren una serie de servicios, estos rara vez son manipulados por el usuario que se limita a ejecutar sus aplicaciones finales.

Sin embargo, en un sistema de servidor, es imprescidible saber cómo manipular y gestionar estos servicios, esto es, cómo, cuáles y por qué arrancan, cómo pararlos de manera ordenada. cómo modificar su arranque y finalmente cómo volverlos a arrancar. De todo esto, es de lo que trata el presente apartado.

Antes de empezar, no obstante, es conveniente dar una pátina de conocimientos sobre cuál es la forma en que arrancan los sistemas UNIX.

Nada más cargar su kernel los sistemas UNIX ejecutan un proceso llamado tradicionalmente init (de initialization) con PID 1, que es el encargado de generar el resto de procesos. Este ejecutable tiene dos estilos para gestionar qué servicios arrancar durante el arranque:

  • El estilo BSD, en el que un único escrito (/etc/rc) se encarga de la gestión.

  • El estilo SystemV (también denominano sysv), en el que la gestión se hace modular por medio de distintos scripts almacenados bajo /etc/rc.d/.

Linux optó por este segundo estilo, con la salvedad de la distribución slackware, más cercano a la filosofía del estilo BSD. La principal limitación del sistema tradicional es que actúa de manera síncrona, de manera que hasta que no se ha completado una tarea no se continúa con la siguiente, lo que dilata los tiempos de arranque. Hubo tanteos para cambiar este sistema de gestión con irregular éxito (Canonical para ubuntu creó upstart), hasta la aparición de systemd, que ha sido adoptado por la mayoría de las grandes distribuciones, con las excepciones de slackware y gentoo. debian fue la última que lo adoptó y arrastró con su decisión a ubuntu, que abandonó upstart.

4.1.1. SysV

Advertencia

SystemV no se usa ya en debian (la última estable que lo uso fue wheezy), de modo que este apartado es meramente informativo y, de hecho, no se entrará en absoluto en detalle1.

En el sistema de arranque basado en SystemV existe un fichero /etc/inittab que controla la configuración para el ejecutable init. Este fichero, entre otros aspectos, indica en qué nivel de ejecución arrancará el sistema. Un nivel de ejecución (o runlevel) define el modo de operación con que actuará el sistema operativo, lo que se traduce en cuáles son los servicios que deben cargarse durante el arranque. En linux los niveles de ejecución típicos son siete:

0: Halt

Apagado del sistema.

1: single-user mode

Modo monousuario. No ejecuta apenas servicios y sólo permite entrar en el sistema con la contraseña del administrador (root). Es el nivel de ejecución en que arranca el ordenador cuando se detecta un problema que exige reparación.2

2: multi-user mode

Modo multiusuario sin funciones de red.

3: multi-user mode with networking

Modo multiusuario con funciones de red.

4: user definible

Modo sin uso específico, de modo que puede definirlo el usuario como mejor convega.

5: multi-user mode with networking and GUI

A los servicios cargados en el runlevel 3, se añade la carga del servidor gráfico.

6: reboot

Reinicio del sistema.

Por lo general, en /etc/inittab se configura el nivel de ejecución predeterminado (normalmente 3 ó 5), aunque en grub se puede añadir alguna entrada que cargue un runlevel distinto. Por ejemplo, es relativamente común que se añada una entrada recovery mode (o modo de recuperación) que arranque el sistema en runlevel 1. Para ello basta con incluir el número del runlevel como parámetro en la carga del núcleo.

Para organizar el arranque al estilo sysv las distribuciones de linux traen un directorio /etc/init.d dentro del cual incluyen todos los scripts que lanzan o paran los servicios y una serie de directorios /etc/rcX.d donde X es el número correspondiente al runlevel. El contenido de estos directorios son enlaces simbólicos a los scripts contenidos en /etc/init.d con nombres tales como S05slim o :file:` o K01slim. El final de estos nombres (slim en el ejemploi) es el nombre del script con el que enlazan; la S o K indica si hay que arrancar o parar el servicio; y el número intermedio el orden en que han de ser arrancados o parados (un número 01 significa que ese script se arrancará antes que uno con número 02). Lo habitual es que los runlevels de arranque (1-5) tengan enlaces simbólicos con S y los runlevels de cierre (0, 6) enlaces simbólicos con K. Además hay un directorio /etc/rc.S que sirve para incluir scripts que se ejecutan al término del arranque, sea cual sea el nivel de ejecución (1-5).

En la práctica en debian y derivadas, no se hace distinción entre los runlevels 2-5, de manera que los runlevels distintos se reducen a 4 (0, 1, 2-5 y 6).

Para gestionar lo explicado y arrancar y parar a mano durante la ejecución del sistema algún servicio, debian dispone de algunas herramientas que se explicarán en la sección Gestión al modo de debian y que se han portado a systemd con lo que siguen siendo válidas, aunque el gestor del sistema haya cambiado.

4.1.2. SystemD

SystemD es nuevo gestor de sistema desarrollado a partir de 2009 en principio para la distribución Red Hat, pero que ha acabado siendo adoptado por la mayoría de las distribuciones modernas de linux, excepto *slackware y gentoo.

Utiliza características exclusivas de linux por lo que no es implementable para otros unices y ha recibido fuertes críticas y hasta hay una wiki para reúne información sobre sistemas linux sin systemd Sea como sea, se ha convertido en el estándar de facto para el arranque de los sistemas linux y, por consiguiente, no queda otra que conocerlo3. En particular nos interesa conocer los siguientes aspectos sobre los servicios4:

4.1.3. Gestión al modo de debian

Aunque de wheezy (7.0) a jessie (8.0) se cambió la gestión del sistema de SystemV a SystemD, debian ha portado también sus herramientas de un sistema a otro5, a fin de que puedan seguirse gestionando los servicios como hasta la fecha.

La ventaja de conocer estas herramientas es que pueden manipularse los servicios de idéntico modo con independencia de cuál versión de debian tratemos. La desventaja es que podemos realizar un número reducido de operaciones.

SystemD

Tradicional

Acción

Con invoke-rc.d

Con service

systemctl start ssh.service

invoke-rc.d ssh start

service ssh start

Arrancar servicio

systemctl stop ssh.service

invoke-rc.d ssh stop

service ssh stop

Parar servicio

systemctl restart ssh.service

invoke-rc.d ssh restart

service ssh restart

Reiniciar servicio

systemctl reload ssh.service

invoke-rc.d ssh reload

service ssh reload

Recargar servicio

systemctl reload-or-restart ssh.service

invoke-rc.d ssh force-reload

service ssh reload

Recargar servicio

systemctl status ssh.service

invoke-rc.d ssh status

service ssh status

Supervisar servicio

systemctl enable ssh.service

update-rc.d ssh enable

Habilitar servicio

systemctl disable ssh.service

update-rc.d ssh disable

Deshabilitar servicio

Notas al pie

1

No obstante, tiene su utilidad conocerlo, ya que debian sigue incluyendo en sus paquetes los scripts para sysv. En cualquier caso, estos scripts no deben ejecutarse directamente. No ahora que la gestión la hace systemd, pero tampoco antes puesto que debian dispone de un conjunto de utilidades para gestionar el arranque. Estas utilidades siguen siendo válidas, puesto que se han portando a systemd y son las que se explican en la sección Gestión al modo de debian.

2

Por ejemplo, si es imposible montar una partición listada en /etc/fstab que no tenga como opción de montaje nofail, se producirá un error que provocará que el sistema pase al runlevel 1.

3

Aunque el método tradicional de gestión de permisos en debian ya está portado a systemd, éste sólo sirve para los servicios ajenos al propio systemd. Por ejemplo, el demonio sshd que habilita el servidor SSH puede gestionarse de este modo, puesto que es un servicio que gestiona, pero no implementa, systemd. Sin embargo, los servicios propios de systemd no hay otra forma de manipularlos que a través de las herramientas de systemd.

4

A los cuales habría que añadir la monitorización, de la que también se encarga systemd, pero que se trata en bajo un epígrafe posterior.

5

En realidad, las herramientas gestionan en paralelo ambos sistemas, ya que en debian puede seguirse instalando SystemV.