Capítulo 3. Gestión de servicios con systemd
3.1. Introducción a systemd
Systemd es un gestor de sistemas y servicios para sistemas operativos Linux. Está diseñado para ser compatible con los scripts de inicio de SysV, y proporciona una serie de características tales como el inicio paralelo de los servicios del sistema en el momento del arranque, la activación bajo demanda de los demonios, o la lógica de control de servicios basada en la dependencia. A partir de Red Hat Enterprise Linux 7, systemd reemplazó a Upstart como el sistema de inicio por defecto.
Systemd introduce el concepto de systemd units. Estas unidades están representadas por archivos de configuración de unidades ubicados en uno de los directorios enumerados en la siguiente tabla.
| Directorio | Descripción |
|---|---|
|
| Archivos de unidad Systemd distribuidos con los paquetes RPM instalados. |
|
| Archivos de unidad Systemd creados en tiempo de ejecución. Este directorio tiene prioridad sobre el directorio con los archivos de unidad de servicio instalados. |
|
|
Los archivos de unidad de Systemd creados por |
Las unidades encapsulan información sobre:
- Servicios del sistema
- Tomas de corriente para escuchar
- Otros objetos relevantes para el sistema init
Para obtener una lista completa de los tipos de unidades systemd disponibles, consulte la siguiente tabla.
| Tipo de unidad | Extensión del archivo | Descripción |
|---|---|---|
| Unidad de servicio |
| Un servicio del sistema. |
| Unidad de destino |
| Un grupo de unidades systemd. |
| Unidad de montaje automático |
| Un punto de montaje automático del sistema de archivos. |
| Unidad de dispositivo |
| Un archivo de dispositivo reconocido por el kernel. |
| Montar la unidad |
| Un punto de montaje del sistema de archivos. |
| Unidad de ruta |
| Un archivo o directorio en un sistema de archivos. |
| Unidad de alcance |
| Un proceso creado externamente. |
| Unidad de corte |
| Un grupo de unidades organizadas jerárquicamente que gestionan los procesos del sistema. |
| Unidad de enchufe |
| Un socket de comunicación entre procesos. |
| Unidad de intercambio |
| Un dispositivo de intercambio o un archivo de intercambio. |
| Unidad de temporizador |
| Un temporizador systemd. |
Anulando la configuración por defecto de systemd mediante system.conf
La configuración por defecto de systemd se define durante la compilación y se puede encontrar en el archivo de configuración de systemd en /etc/systemd/system.conf. Utilice este archivo si desea desviarse de esos valores predeterminados y anular los valores predeterminados seleccionados para las unidades de systemd de forma global.
Por ejemplo, para anular el valor por defecto del límite de tiempo de espera, que está fijado en 90 segundos, utilice el parámetro DefaultTimeoutStartSec para introducir el valor requerido en segundos.
DefaultTimeoutStartSec=required valuePara más información, consulte Ejemplo 3.11, “Cambiar el límite de tiempo de espera”.
3.1.1. Características principales
El sistema systemd y el gestor de servicios proporcionan las siguientes características principales:
Socket-based activation - En el momento del arranque, systemd crea sockets de escucha para todos los servicios del sistema que soportan este tipo de activación, y pasa los sockets a estos servicios tan pronto como se inician. Esto no sólo permite systemd iniciar servicios en paralelo, sino que también hace posible reiniciar un servicio sin perder ningún mensaje enviado a él mientras no está disponible: el socket correspondiente sigue siendo accesible y todos los mensajes se ponen en cola.
Systemd utiliza socket units para la activación basada en sockets.
- Bus-based activation - Los servicios del sistema que utilizan D-Bus para la comunicación entre procesos pueden iniciarse bajo demanda la primera vez que una aplicación cliente intenta comunicarse con ellos Systemd utiliza D-Bus service files para la activación basada en el bus.
- Device-based activation - Los servicios del sistema que admiten la activación basada en dispositivos pueden iniciarse a petición cuando se conecta un tipo concreto de hardware o está disponible Systemd utiliza device units para la activación basada en dispositivos.
- Path-based activation - Los servicios del sistema que soportan la activación basada en la ruta pueden iniciarse bajo demanda cuando un archivo o directorio concreto cambia de estado Systemd utiliza path units para la activación basada en la ruta.
- Mount and automount point management - Systemd controla y gestiona los puntos de montaje y automontaje Systemd utiliza mount units para los puntos de montaje y automount units para los puntos de automontaje.
- Aggressive parallelization - Debido al uso de la activación basada en sockets, systemd puede iniciar los servicios del sistema en paralelo tan pronto como todos los sockets de escucha están en su lugar. En combinación con los servicios del sistema que soportan la activación bajo demanda, la activación en paralelo reduce significativamente el tiempo necesario para arrancar el sistema.
- Transactional unit activation logic - Antes de activar o desactivar una unidad, systemd calcula sus dependencias, crea una transacción temporal y verifica que esta transacción sea consistente. Si una transacción es inconsistente systemd intenta automáticamente corregirla y eliminar de ella los trabajos no esenciales antes de informar de un error.
- Backwards compatibility with SysV init - Systemd soporta los scripts de init de SysV como se describe en el Linux Standard Base Core Specificationlo que facilita la ruta de actualización de las unidades de servicio systemd.
3.1.2. Cambios de compatibilidad
El sistema systemd y el gestor de servicios están diseñados para ser mayormente compatibles con SysV init y Upstart. Los siguientes son los cambios de compatibilidad más notables con respecto al sistema Red Hat Enterprise Linux 6 que utilizaba SysV init:
-
Systemd sólo tiene un soporte limitado para los niveles de ejecución. Proporciona una serie de unidades de destino que se pueden asignar directamente a estos niveles de ejecución y, por razones de compatibilidad, también se distribuye con el comando anterior
runlevel. Sin embargo, no todos los objetivos de systemd pueden ser asignados directamente a niveles de ejecución, y como consecuencia, este comando puede devolverNpara indicar un nivel de ejecución desconocido. Se recomienda evitar el uso del comandorunlevelsi es posible. Para obtener más información sobre los objetivos de systemd y su comparación con los niveles de ejecución, consulte Sección 3.3, “Trabajar con objetivos systemd”. La utilidad
systemctlno admite comandos personalizados. Además de los comandos estándar comostart,stop, ystatus, los autores de los scripts de init de SysV podrían implementar soporte para cualquier número de comandos arbitrarios con el fin de proporcionar funcionalidad adicional. Por ejemplo, el script de init paraiptablespodría ser ejecutado con el comandopanic, que inmediatamente activaría el modo de pánico y reconfiguraría el sistema para comenzar a dejar caer todos los paquetes entrantes y salientes. Esto no está soportado en systemd y elsystemctlsólo acepta comandos documentados.Para más información sobre la utilidad
systemctly su comparación con la anteriorservice, consulte Tabla 3.3, “Comparación de la utilidad de servicio con systemctl”.-
La utilidad
systemctlno se comunica con los servicios que no han sido iniciados por systemd. Cuando systemd inicia un servicio del sistema, almacena el ID de su proceso principal para poder seguirlo. La utilidadsystemctlutiliza entonces este PID para consultar y gestionar el servicio. En consecuencia, si un usuario inicia un demonio concreto directamente en la línea de comandos,systemctlno puede determinar su estado actual ni detenerlo. -
Systemd detiene sólo los servicios en ejecución. Anteriormente, cuando se iniciaba la secuencia de apagado, Red Hat Enterprise Linux 6 y las versiones anteriores del sistema utilizaban enlaces simbólicos ubicados en el directorio
/etc/rc0.d/para detener todos los servicios del sistema disponibles, independientemente de su estado. Con systemd sólo se detienen los servicios en ejecución al apagar el sistema. -
Los servicios del sistema no pueden leer del flujo de entrada estándar. Cuando systemd inicia un servicio, conecta su entrada estándar a
/dev/nullpara evitar cualquier interacción con el usuario. -
Los servicios del sistema no heredan ningún contexto (como las variables de entorno
HOMEyPATH) del usuario que los invoca y de su sesión. Cada servicio se ejecuta en un contexto de ejecución limpio. - Cuando se carga un script de init de SysV, systemd lee la información de dependencia codificada en la cabecera Linux Standard Base (LSB) y la interpreta en tiempo de ejecución.
- Todas las operaciones en unidades de servicio están sujetas a un tiempo de espera por defecto de 5 minutos para evitar que un servicio que funcione mal congele el sistema. Este valor está codificado para los servicios que se generan a partir de los initscripts y no se puede cambiar. Sin embargo, se pueden utilizar archivos de configuración individuales para especificar un valor de tiempo de espera más largo por servicio, ver Ejemplo 3.11, “Cambiar el límite de tiempo de espera”.
Para una lista detallada de los cambios de compatibilidad introducidos con systemdconsulte el Manual de planificación de la migración para Red Hat Enterprise Linux 7.
