Centro de Conocimiento DevOps
Centro de Conocimiento DevOps

Cómo Escribir y Gestionar Archivos de Unidad systemd Personalizados de Forma Efectiva

Domine el arte de gestionar sus servicios de Linux con esta guía completa sobre archivos de unidad systemd personalizados. Aprenda a crear, configurar y solucionar problemas de archivos `.service`, aprovechando directivas cruciales como `ExecStart`, `WantedBy` y `Type`. Este artículo proporciona instrucciones paso a paso y ejemplos prácticos, lo que le permitirá estandarizar el inicio de aplicaciones, garantizar un funcionamiento fiable e integrar sus procesos personalizados de forma fluida en su entorno de sistema Linux. Esencial para desarrolladores y administradores que buscan una gestión de servicios robusta.

36 vistas

Cómo Escribir y Gestionar Archivos de Unidad Custom de Systemd de Forma Eficaz

Las distribuciones modernas de Linux utilizan predominantemente systemd como su sistema de inicialización y gestor de servicios. Comprender systemd es crucial para cualquier administrador de sistemas Linux o desarrollador que necesite desplegar y gestionar aplicaciones de forma fiable. Aunque muchas aplicaciones vienen con archivos de unidad systemd precompilados, la capacidad de escribir archivos de unidad personalizados le permite estandarizar el inicio, la parada y la gestión general del ciclo de vida de sus propias aplicaciones, scripts o cualquier proceso personalizado.

Este artículo le guiará a través del proceso de creación, configuración y gestión de archivos de unidad .service personalizados de systemd. Exploraremos las directivas esenciales que definen cómo se ejecuta su aplicación, establecen dependencias y garantizan un funcionamiento robusto. Al final, estará equipado para integrar sus servicios personalizados sin problemas en el sistema operativo Linux, asegurando que se inicien automáticamente al arrancar, se reinicien en caso de fallo y se gestionen fácilmente usando systemctl.

Dominar los archivos de unidad personalizados de systemd proporciona un control granular sobre sus servicios, mejora la estabilidad del sistema y simplifica las tareas administrativas. Sumergámonos en los componentes principales y los pasos prácticos necesarios para gestionar sus aplicaciones como un profesional.

Entendiendo los Archivos de Unidad de Systemd

Systemd gestiona varios recursos del sistema, conocidos como unidades, que se definen mediante archivos de configuración. Estas unidades incluyen servicios (.service), puntos de montaje (.mount), dispositivos (.device), sockets (.socket), y más. Para la gestión de aplicaciones y procesos en segundo plano, el tipo de unidad .service es el más común y relevante.

Los archivos de unidad de systemd son archivos de texto plano que normalmente se almacenan en directorios específicos. Las ubicaciones principales, en orden de precedencia, son:

  • /etc/systemd/system/: Esta es la ubicación recomendada para archivos de unidad personalizados y anulaciones, ya que tienen prioridad sobre los valores predeterminados del sistema y persisten en las actualizaciones del sistema.
  • /run/systemd/system/: Se utiliza para archivos de unidad generados en tiempo de ejecución.
  • /usr/lib/systemd/system/: Contiene archivos de unidad proporcionados por paquetes instalados. No modifique los archivos de este directorio directamente.

Al colocar sus archivos de unidad personalizados en /etc/systemd/system/, se asegura de que sean reconocidos y gestionados correctamente por systemd.

Anatomía de un Archivo de Unidad .service

Un archivo de unidad .service de systemd está estructurado en varias secciones, cada una denotada por [NombreDeSección], que contiene varias directivas (pares clave-valor). Las tres secciones principales para una unidad de servicio son [Unit], [Service] y [Install].

Analicemos las directivas más cruciales que utilizará:

Sección [Unit]

Esta sección contiene opciones genéricas sobre la unidad, su descripción y sus dependencias.

  • Description: Una cadena de texto legible por humanos que describe el servicio. Esto aparece en la salida de systemctl status.
    ini Description=Mi Aplicación Web Personalizada en Python
  • Documentation: Una URL que apunta a la documentación del servicio (opcional).
    ini Documentation=https://ejemplo.com/docs/mi-app
  • After: Especifica que esta unidad debe iniciarse después de las unidades listadas. Esto ayuda a gestionar el orden de inicio. Para aplicaciones web, es posible que desee asegurarse de que la red esté activa.
    ini After=network.target
  • Requires: Similar a After, pero implica una dependencia más fuerte. Si la unidad requerida falla, esta unidad no se iniciará o se detendrá.
    ini Requires=docker.service
  • Wants: Una forma más débil de Requires. Si la unidad deseada falla o no se encuentra, esta unidad aún intentará iniciarse. Generalmente se prefiere a Requires para dependencias no críticas.
    ini Wants=syslog.target

Sección [Service]

Esta sección define los parámetros de ejecución de su servicio, incluyendo cómo se inicia, se detiene y se comporta.

  • Type: Define el tipo de inicio del proceso. Crítico para cómo systemd supervisa su servicio.

    • simple (por defecto): El comando ExecStart es el proceso principal del servicio. Systemd considera que el servicio se inició inmediatamente después de invocar ExecStart. Espera que el proceso se ejecute indefinidamente en primer plano.
    • forking: El comando ExecStart bifurca un proceso hijo y el padre sale. Systemd considera que el servicio se inició una vez que el proceso padre sale. Utilice esto si su aplicación se daemoniza a sí misma.
    • oneshot: El comando ExecStart es un proceso de una sola vez que sale cuando ha terminado. Útil para scripts que realizan una tarea y terminan (por ejemplo, un script de copia de seguridad).
    • notify: Similar a simple, pero el servicio envía una notificación a systemd cuando está listo. Requiere libsystemd-dev y código específico en su aplicación.
    • idle: El comando ExecStart se ejecuta solo cuando todos los trabajos han finalizado, retrasando la ejecución hasta que el sistema esté mayormente inactivo.

    ini Type=simple

  • ExecStart: El comando a ejecutar cuando el servicio se inicia. Esta es la directiva más importante de esta sección. Utilice siempre la ruta absoluta a su ejecutable o script.
    ini ExecStart=/usr/bin/python3 /opt/mi_app/app.py

  • ExecStop: El comando a ejecutar cuando el servicio se detiene (opcional). Si no se especifica, systemd envía SIGTERM a los procesos.
    ini ExecStop=/usr/bin/pkill -f 'mi_app/app.py'
  • ExecReload: El comando a ejecutar para recargar la configuración del servicio (opcional).
    ini ExecReload=/bin/kill -HUP $MAINPID
  • User: La cuenta de usuario bajo la cual se ejecutarán los procesos del servicio. Esencial para la seguridad; evite root a menos que sea absolutamente necesario.
    ini User=usuario_mi_app
  • Group: La cuenta de grupo bajo la cual se ejecutarán los procesos del servicio.
    ini Group=grupo_mi_app
  • WorkingDirectory: El directorio de trabajo para los comandos ejecutados.
    ini WorkingDirectory=/opt/mi_app
  • Restart: Define cuándo se debe reiniciar automáticamente el servicio.
    • no (por defecto): Nunca reiniciar.
    • on-success: Reiniciar solo si el servicio sale limpiamente.
    • on-failure: Reiniciar solo si el servicio sale con un código de estado distinto de cero o es terminado por una señal.
    • always: Reiniciar siempre el servicio, independientemente del estado de salida.
      ini Restart=on-failure
  • RestartSec: Cuánto tiempo esperar antes de reiniciar el servicio (por ejemplo, 5s para 5 segundos).
    ini RestartSec=5s
  • Environment: Establece variables de entorno para los comandos ejecutados.
    ini Environment="APP_ENV=production" "DEBUG=false"
  • EnvironmentFile: Lee variables de entorno de un archivo. Cada línea debe ser CLAVE=VALOR.
    ini EnvironmentFile=/etc/default/mi_app
  • LimitNOFILE: Establece el número máximo de descriptores de archivo abiertos permitidos para el servicio (por ejemplo, 100000). Importante para aplicaciones de alta concurrencia.
    ini LimitNOFILE=65536

Sección [Install]

Esta sección define cómo se habilita el servicio para iniciarse automáticamente al arrancar.

  • WantedBy: Especifica la unidad de destino que "desea" este servicio. Cuando se habilita la unidad de destino, este servicio se enlazará simbólicamente en su directorio .wants, lo que efectivamente hará que se inicie con el destino.
    • multi-user.target: El destino estándar para la mayoría de los servicios de servidor, que indica un sistema con inicios de sesión multiusuario no gráficos.
    • graphical.target: Para servicios que requieren un entorno gráfico.
      ini WantedBy=multi-user.target
  • RequiredBy: Similar a WantedBy, pero una dependencia más fuerte. Si el destino está habilitado, esta unidad también está habilitada, y si esta unidad falla, el destino también fallará.

Consejo: Para la mayoría de los servicios personalizados destinados a ejecutarse en segundo plano en un servidor, Type=simple y WantedBy=multi-user.target son las opciones más comunes y apropiadas.

Paso a Paso: Creación y Gestión de un Servicio Systemd Personalizado

Creemos un ejemplo práctico: un servidor HTTP simple en Python que sirve archivos desde un directorio especificado. Lo configuraremos como un servicio systemd.

Paso 1: Preparar su Aplicación/Script

Primero, cree el script de la aplicación. Para este ejemplo, usaremos un servidor HTTP simple en Python. Cree un directorio para su aplicación, por ejemplo, /opt/my_app, y coloque app.py dentro.

# /opt/my_app/app.py

import http.server
import socketserver
import os

PORT = int(os.environ.get("PORT", 8000))
DIRECTORY = os.environ.get("DIRECTORY", os.getcwd())

class Handler(http.server.SimpleHTTPRequestHandler):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, directory=DIRECTORY, **kwargs)

print(f"Sirviendo el directorio {DIRECTORY} en el puerto {PORT}")

with socketserver.TCPServer(("", PORT), Handler) as httpd:
    print("Servidor iniciado.")
    httpd.serve_forever()

Cree el directorio y el archivo:

sudo mkdir -p /opt/mi_app
sudo nano /opt/mi_app/app.py

(Pegue el código de Python)

Asegúrese de que el script sea ejecutable (opcional para el comando python3, pero buena práctica):

sudo chmod +x /opt/mi_app/app.py

Considere crear un usuario dedicado para su servicio por razones de seguridad:

sudo useradd --system --no-create-home usuario_mi_app

Establezca la propiedad adecuada para el directorio de su aplicación:

sudo chown -R usuario_mi_app:usuario_mi_app /opt/mi_app

Paso 2: Crear el Archivo de Unidad

Ahora, cree el archivo de unidad systemd para nuestra aplicación Python. Lo llamaremos my_app.service.

sudo nano /etc/systemd/system/my_app.service

Pegue el siguiente contenido:

# /etc/systemd/system/my_app.service

[Unit]
Description=Mi Servidor HTTP Personalizado en Python
Documentation=https://github.com/ejemplo/mi_app
After=network.target

[Service]
Type=simple
User=usuario_mi_app
Group=grupo_mi_app
WorkingDirectory=/opt/mi_app
Environment="PORT=8080" "DIRECTORY=/var/www/html"
ExecStart=/usr/bin/python3 /opt/mi_app/app.py
Restart=on-failure
RestartSec=10s
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Nota: Hemos establecido StandardOutput=journal y StandardError=journal para dirigir la salida del servicio al journal de systemd, lo que facilita la visualización de los registros con journalctl.

Paso 3: Colocar el Archivo de Unidad

Como se indicó, hemos colocado el archivo de unidad en /etc/systemd/system/. Aquí es donde deben residir los archivos de unidad personalizados.

Paso 4: Recargar el Demonio de Systemd

Después de crear o modificar un archivo de unidad, systemd debe ser informado de los cambios. Esto se hace recargando el demonio de systemd:

sudo systemctl daemon-reload

Paso 5: Iniciar el Servicio

Ahora puede iniciar su servicio:

sudo systemctl start my_app.service

Paso 6: Comprobar el Estado del Servicio y los Registros

Verifique que su servicio se esté ejecutando correctamente:

systemctl status my_app.service

Ejemplo de salida (truncada):

● my_app.service - Mi Servidor HTTP Personalizado en Python
     Loaded: loaded (/etc/systemd/system/my_app.service; disabled; vendor preset: enabled)
     Active: active (running) since Tue 2023-10-26 10:30:00 UTC; 5s ago
       Docs: https://github.com/ejemplo/mi_app
   Main PID: 12345 (python3)
      Tasks: 1 (limit: 1100)
     Memory: 6.5M
        CPU: 45ms
     CGroup: /system.slice/my_app.service
             └─12345 /usr/bin/python3 /opt/mi_app/app.py

Oct 26 10:30:00 suhostname python3[12345]: Sirviendo el directorio /var/www/html en el puerto 8080
Oct 26 10:30:00 suhostname python3[12345]: Servidor iniciado.

Para ver los registros del servicio, use journalctl:

journalctl -u my_app.service -f

Este comando muestra los registros de my_app.service y -f (seguir) mostrará los nuevos registros en tiempo real.

También puede probar el servidor desde su navegador o con curl en http://localhost:8080 (suponiendo que /var/www/html exista y contenga algunos archivos).

Paso 7: Habilitar el Servicio para Inicio Automático

Para que su servicio se inicie automáticamente cada vez que el sistema arranca, necesita habilitarlo:

sudo systemctl enable my_app.service

Este comando crea un enlace simbólico de /etc/systemd/system/multi-user.target.wants/my_app.service a /etc/systemd/system/my_app.service.

Paso 8: Detener y Deshabilitar el Servicio

Para detener un servicio en ejecución:

sudo systemctl stop my_app.service

Para evitar que un servicio se inicie automáticamente al arrancar (mientras lo deja habilitado para ser iniciado manualmente):

sudo systemctl disable my_app.service

Si desea eliminar el servicio por completo, primero deshabilítelo, luego deténgalo, y finalmente elimine el archivo .service de /etc/systemd/system/ y ejecute sudo systemctl daemon-reload.

Paso 9: Actualizar un Servicio

Si modifica su script app.py o el archivo de unidad my_app.service, deberá actualizar systemd y reiniciar el servicio:

  1. Edite /opt/my_app/app.py o /etc/systemd/system/my_app.service.
  2. Si modificó el archivo de unidad, ejecute sudo systemctl daemon-reload.
  3. Reinicie el servicio: sudo systemctl restart my_app.service.

Mejores Prácticas y Solución de Problemas

  • Rutas Absolutas: Utilice siempre rutas absolutas para ExecStart, WorkingDirectory, y cualquier otra ruta de archivo dentro de su archivo de unidad. Las rutas relativas pueden llevar a un comportamiento inesperado.
  • Usuarios Dedicados: Ejecute los servicios bajo cuentas de usuario dedicadas y no privilegiadas (por ejemplo, usuario_mi_app) para mejorar la seguridad y limitar el daño potencial en caso de compromiso.
  • Registro Claro: Utilice StandardOutput=journal y StandardError=journal para dirigir la salida del servicio al journal de systemd. Use journalctl -u <nombre_del_servicio> para ver los registros.
  • Dependencias: Considere cuidadosamente After, Wants y Requires para asegurar que su servicio se inicie en el orden correcto en relación con sus dependencias (por ejemplo, red, bases de datos).
  • Prueba de Cambios: Antes de habilitar un servicio para que se inicie al arrancar, pruébelo a fondo iniciándolo y deteniéndolo manualmente. Verifique su estado y registros.
  • Límites de Recursos: Utilice directivas como LimitNOFILE, LimitNPROC, MemoryLimit, etc., para evitar que los servicios descontrolados consuman todos los recursos del sistema.
  • Variables de Entorno: Utilice Environment= o EnvironmentFile= para los valores de configuración que puedan cambiar o variar entre entornos, en lugar de codificarlos en el archivo de unidad o script.
  • Manejo de Errores en Scripts: Asegúrese de que sus scripts de aplicación manejen los errores de forma elegante. Un código de salida distinto de cero activará Restart=on-failure.

Advertencia: Evite modificar los archivos de unidad directamente en /usr/lib/systemd/system/. Cualquier cambio probablemente será sobrescrito por las actualizaciones de paquetes. Utilice /etc/systemd/system/ para unidades personalizadas o anulaciones.

Conclusión

Los archivos de unidad de systemd son un mecanismo potente y flexible para gestionar procesos y aplicaciones en sistemas Linux. Al comprender su estructura y sus directivas clave, puede estandarizar eficazmente el inicio, la parada y la supervisión de sus servicios personalizados, mejorando la estabilidad del sistema y simplificando la administración. Desde la definición de comandos de inicio con ExecStart hasta la gestión de dependencias con After y la habilitación del inicio automático con WantedBy, ahora tiene las herramientas para integrar sus aplicaciones sin problemas en el ecosistema de systemd. Esta habilidad fundamental es invaluable para mantener implementaciones de Linux robustas y fiables.

Continúe explorando funciones avanzadas de systemd como temporizadores (.timer), activación por socket (.socket) y cgroups para escenarios de gestión de servicios más sofisticados.