Gestión de servicios con systemd: creación, arranque, parada, habilitación y diagnóstico

Objetivo:

Aprender a gestionar el ciclo de vida completo de los servicios en sistemas operativos Linux modernos basados en systemd, dominando las herramientas de control de daemons (systemctl) y la auditoría avanzada de registros (journalctl).

Escenario:

  • Herramientas: Terminal Linux, systemctl, journalctl, editores de texto (Nano), archivos de unidades de servicio (.service).
  • Conceptos analizados: Inicialización del sistema, demonios (*daemons*), estados de servicios (activo, detenido, fallido, enmascarado), dependencias de arranque y el diario centralizado de systemd.
  • Proceso clave: Creación de una unidad de servicio personalizada, control de arranque/parada, habilitación en el inicio del sistema, diagnóstico de fallos y filtrado de logs mediante journalctl.

Escenario Real: Desplegar y monitorizar un servicio crítico

Un nuevo servicio web o aplicación interna desarrollada a medida necesita integrarse formalmente en el sistema operativo para que arranque de manera automática al encender la máquina, se mantenga activo en segundo plano (*daemon*) y se reinicie automáticamente si sufre un fallo inesperado. Como administrador de sistemas, debes empaquetar este proceso creando una unidad oficial de systemd, comprobar su estado de salud y auditar los registros en tiempo real ante cualquier incidencia técnica.

En las distribuciones Linux modernas, **systemd** actúa como el sistema de inicialización (*init*) y gestor principal del sistema y de los servicios (siendo el proceso PID 1). A diferencia de los sistemas de arranque antiguos basados en scripts de System V, systemd gestiona los servicios mediante unidades de configuración declarativas y permite un control granular de las dependencias, la concurrencia en el arranque y la monitorización centralizada de logs.

NOTA: Esta práctica se realizará de forma controlada sobre nuestro entorno Linux de prácticas habitual, utilizando un script o servicio web sencillo para ilustrar la creación de daemons personalizados.

Instrucciones:

Fase 1: Gestión básica de servicios nativos existentes:

  • Comprobar el estado actual de un servicio nativo del sistema (por ejemplo, el servidor web nginx o el servicio SSH ssh): 
    sudo systemctl status ssh
  • Detener la ejecución temporalmente del servicio: 
    sudo systemctl stop ssh
  • Volver a arrancar el servicio y comprobar que su estado cambia a activo (*active (running)*): 
    sudo systemctl start ssh
  • Reiniciar o recargar la configuración del servicio sin perder conexiones activas: 
    sudo systemctl restart ssh

Fase 2: Habilitación y persistencia en el arranque del sistema:

  • Para lograr que un servicio se inicie de forma automática cada vez que se enciende o reinicia el servidor, debemos **habilitarlo**: 
    sudo systemctl enable ssh
  • Para comprobar si un servicio está configurado para arrancar automáticamente en el inicio: 
    systemctl is-enabled ssh
  • Si en algún momento necesitamos evitar por completo que un servicio pueda ser ejecutado (incluso de forma manual por error), podemos **enmascararlo**: 
    sudo systemctl mask ssh
NOTA: El enmascaramiento (*mask*) crea un enlace simbólico del servicio hacia /dev/null, bloqueando totalmente cualquier intento de arranque. Para revertir esta acción se utiliza el comando sudo systemctl unmask ssh.

Fase 3: Creación de una unidad de servicio personalizada (*.service*):

  • Crear un archivo de configuración para un servicio propio en el directorio de unidades del sistema: 
    sudo nano /etc/systemd/system/mi-servicio.service
  • Añadir la estructura declarativa básica especificando la descripción, el comando de ejecución y las directivas de reintento: 
    [Unit]
Description=Mi Servicio Personalizado de Practicas
After=network.target

[Service]
ExecStart=/usr/bin/python3 -m http.server 8080
Restart=on-failure

[Install]
WantedBy=multi-user.target
  • Guardar los cambios (Ctrl+O) y salir del editor (Ctrl+X).

Fase 4: Recarga del demonio y despliegue del servicio propio:

  • Cada vez que se crea o modifica un archivo de unidad en /systemd/system/, es obligatorio notificar al núcleo para que relea las configuraciones: 
    sudo systemctl daemon-reload
  • Habilitar y arrancar nuestro nuevo servicio personalizado: 
    sudo systemctl enable --now mi-servicio.service

Fase 5: Diagnóstico y auditoría avanzada con journalctl:

  • El comando journalctl recopila y centraliza todos los registros del núcleo y de los servicios gestionados por systemd. Para consultar los logs específicos de nuestro servicio en tiempo real: 
    sudo journalctl -u mi-servicio.service -f
  • Para visualizar únicamente los errores críticos registrados por todos los servicios del sistema desde el último arranque: 
    journalctl -p err -b

Verificación:

  • Verificar el funcionamiento del servicio personalizado accediendo a su puerto mediante curl http://localhost:8080 o comprobando su estado con sudo systemctl status mi-servicio.service.
  • Comprobar la lista general de servicios que se encuentran actualmente en estado de fallo (*failed*): systemctl --failed

Posibles errores y resolución de problemas:

Si al intentar arrancar un servicio personalizado aparece un error crítico indicando que el servicio ha fallado con código de salida (code=exited, status=203/EXEC), suele deberse a que la ruta del ejecutable especificada en la directiva ExecStart es incorrecta o el archivo no tiene permisos de ejecución.

  • Solución: Comprueba la ruta absoluta exacta del comando mediante which nombre_comando y actualiza el archivo de unidad en /etc/systemd/system/mi-servicio.service, seguido de sudo systemctl daemon-reload.

Preguntas de reflexión:

  1. ¿Qué diferencia fundamental existe entre los estados de un servicio al utilizar los comandos disable y mask dentro de systemd?
  2. ¿Por qué es obligatorio ejecutar el comando sudo systemctl daemon-reload después de modificar o crear un archivo de unidad en /etc/systemd/system/?
  3. ¿Qué ventajas aporta el uso del diario centralizado de systemd (journalctl) frente al almacenamiento tradicional de logs en archivos de texto plano dentro de /var/log/?
  4. ¿Qué función cumple la directiva Restart=on-failure en la sección [Service] de una unidad y por qué es clave en entornos de alta disponibilidad?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Qué diferencia fundamental existe entre los estados de un servicio al utilizar los comandos disable y mask dentro de systemd?

disable elimina los enlaces simbólicos de inicio, impidiendo que el servicio arrancar de forma automática con el sistema, pero permitiendo que pueda ser iniciado manualmente en cualquier momento. mask, en cambio, anula por completo el servicio redirigiendo su unidad a /dev/null, bloqueando tanto el arranque automático como cualquier intento de inicio manual hasta que se des enmascare explícitamente.

2. ¿Por qué es obligatorio ejecutar el comando sudo systemctl daemon-reload después de modificar o crear un archivo de unidad en /etc/systemd/system/?

Porque el proceso PID 1 de systemd mantiene en la memoria RAM una caché con la estructura y metadatos de todas las unidades leídas al arrancar. Si se modifica un archivo de configuración en disco sin recargar el demonio, systemd seguirá aplicando las directivas antiguas hasta que se le ordene explícitamente releer las modificaciones.

3. ¿Qué ventajas aporta el uso del diario centralizado de systemd (journalctl) frente al almacenamiento tradicional de logs en archivos de texto plano dentro de /var/log/?

El diario de systemd almacena los registros en formato binario indexado y comprimido, lo que permite realizar búsquedas estructuradas sumamente rápidas por metadatos (por usuario, PID, unidad de servicio, prioridad o rangos de tiempo específicos), además de integrar un control de integridad criptográfica para evitar alteraciones maliciosas de los registros.

4. ¿Qué función cumple la directiva Restart=on-failure en la sección [Service] de una unidad y por qué es clave en entornos de alta disponibilidad?

Indica a systemd que si el proceso del servicio termina de forma inesperada debido a un error de código, un fallo de segmentación o una caída anómala (es decir, con un código de salida distinto de cero), debe reiniciarlo automáticamente sin intervención humana, garantizando la resiliencia y la continuidad del servicio en producción.