Administración de Sistemas con Systemd: Servicios, Timers y Logs

Systemd se ha convertido en el pilar fundamental de la administración de sistemas en la mayoría de las distribuciones Linux modernas. Desde su adopción masiva, ha reemplazado a los antiguos scripts SysVinit, ofreciendo un ecosistema unificado para gestionar servicios, temporizadores, registros y el arranque del sistema. Para cualquier SysAdmin, dominar systemd no es opcional: es una necesidad para garantizar la fiabilidad, el rendimiento y la capacidad de depuración de los servidores.

Este artículo es una guía exhaustiva sobre los tres pilares de systemd que más utilizarás en tu día a día: servicios, timers y logs. Aprenderás a crear unidades robustas, automatizar tareas con temporizadores y explotar el potente sistema de registro journald. Prepárate para dejar de lado los scripts obsoletos y adoptar un enfoque moderno, declarativo y eficiente.

Servicios Linux con Systemd: Más Allá de start y stop

Los servicios son el corazón de cualquier sistema. En systemd, cada servicio se define mediante un unit file (archivo de unidad) con extensión .service. Estos archivos son de texto plano y se almacenan en ubicaciones estándar: /etc/systemd/system/ (para unidades del administrador) y /lib/systemd/system/ (para unidades del sistema). La prioridad de /etc sobre /lib te permite sobrescribir configuraciones sin modificar los paquetes originales.

Anatomía de un Unit File de Servicio

Un archivo de servicio típico se divide en secciones. Las más importantes son [Unit], [Service] y [Install]. Veamos un ejemplo práctico para un servicio web personalizado:

[Unit]
Description=Mi Servicio Web Personalizado
Documentation=https://ejemplo.com/docs
After=network.target
Wants=network-online.target

[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/var/www/miapp
ExecStart=/usr/bin/node /var/www/miapp/server.js
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5
Environment=NODE_ENV=production
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Explicación de directivas clave:

• [Unit]: Define metadatos y dependencias.
  • After=network.target: Asegura que el servicio arranque después de que la red esté disponible.
  • Wants=network-online.target: Declara una dependencia débil; si falla, el servicio sigue iniciándose.
• [Service]: Configura el comportamiento del proceso.
  • Type=simple: El proceso principal se inicia directamente (el más común). Otros tipos son forking, oneshot, dbus, etc.
  • ExecStart: El comando que inicia el servicio. Siempre usa rutas absolutas.
  • Restart=on-failure: Política de reinicio automático. always, on-success, on-abnormal son otras opciones.
  • StandardOutput=journal: Redirige la salida estándar al sistema de logs de systemd (journald).
• [Install]: Define cómo se habilita el servicio.
  • WantedBy=multi-user.target: El servicio se inicia en el nivel de ejecución multiusuario (sin interfaz gráfica).

Ciclo de Vida y Comandos Esenciales

Gestionar un servicio es intuitivo con systemctl:

• Iniciar/Detener/Reiniciar: sudo systemctl start mi-servicio.service, stop, restart.
• Recargar configuración: sudo systemctl reload mi-servicio.service (envía SIGHUP, si se define ExecReload).
• Habilitar/Deshabilitar en arranque: sudo systemctl enable mi-servicio.service (crea enlaces simbólicos). disable los elimina.
• Ver estado: systemctl status mi-servicio.service (muestra PID, uso de memoria, últimas líneas de log, si está activo, etc.).
• Listar servicios: systemctl list-units --type=service --state=running (solo los que corren).

[TIP] Para ver el contenido completo de una unidad (incluyendo valores por defecto), usa systemctl cat mi-servicio.service. Para ver las dependencias, systemctl list-dependencies mi-servicio.service.

Creación de un Servicio Personalizado Paso a Paso

Supongamos que necesitas un servicio que ejecute un script de backup cada hora. Crearás un unit file de tipo oneshot (se ejecuta una vez y termina).

1. Crea el script /usr/local/bin/backup.sh y hazlo ejecutable.
2. Crea el archivo /etc/systemd/system/backup.service:

[Unit]
Description=Servicio de Backup Diario
After=network.target

[Service]
Type=oneshot
User=root
ExecStart=/usr/local/bin/backup.sh
StandardOutput=journal
StandardError=journal

3. Recarga systemd: sudo systemctl daemon-reload
4. Prueba el servicio: sudo systemctl start backup.service
5. Verifica el estado: systemctl status backup.service

¡Listo! Ahora tienes un servicio que puede ejecutarse bajo demanda o ser invocado por un timer.

Timers: La Evolución de Cron

Los timers de systemd son la alternativa moderna a cron. Ofrecen más flexibilidad, integración con el sistema de logs y manejo de dependencias. Un timer es un unit file que dispara un servicio cuando se cumple una condición temporal. Se definen con extensión .timer y deben tener el mismo nombre que el servicio que activan (ej: backup.timer activa backup.service).

Ventajas Frente a Cron

• Monitoreo centralizado: Los timers y sus servicios asociados se gestionan con systemctl y journalctl.
• Manejo de fallos: Puedes configurar reintentos, notificaciones y acciones en caso de error.
• Calendarios flexibles: Usa expresiones de calendario (similar a cron) o temporizadores monotónicos (relativos a eventos como el arranque).
• Persistencia: Los timers pueden recordar cuándo se ejecutaron por última vez, incluso tras reinicios.

Tipos de Timers

1. Monotónicos: Se basan en eventos del sistema (arranque, activación de unidad, etc.). Ideales para tareas periódicas sin importar la hora del día.

   • OnBootSec=5min: Ejecuta el servicio 5 minutos después del arranque.
   • OnUnitActiveSec=1h: Ejecuta el servicio 1 hora después de la última activación del servicio asociado.
   • OnUnitInactiveSec=30m: Ejecuta el servicio 30 minutos después de que el servicio asociado se detenga.

2. Calendario: Usan una sintaxis similar a cron pero más expresiva.

   • OnCalendar=*-*-* 02:00:00: Todos los días a las 2:00 AM.
   • OnCalendar=Mon..Fri 09:00:00: De lunes a viernes a las 9:00 AM.
   • OnCalendar=*-*-01..07 03:00:00: Del día 1 al 7 de cada mes a las 3:00 AM.

Ejemplo Práctico: Timer para el Servicio de Backup

Usaremos el servicio backup.service creado anteriormente. Ahora creamos su timer:

/etc/systemd/system/backup.timer

[Unit]
Description=Timer para Backup Diario
Requires=backup.service

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=10min

[Install]
WantedBy=timers.target

Explicación:

• OnCalendar=daily: Equivalente a *-*-* 00:00:00. Otras opciones: hourly, weekly, monthly.
• Persistent=true: Si el sistema estaba apagado cuando debía ejecutarse, se ejecutará inmediatamente al encender.
• RandomizedDelaySec=10min: Añade un retardo aleatorio de hasta 10 minutos para evitar sobrecargas en el sistema (muy útil para tareas masivas).
• WantedBy=timers.target: El timer se activa en el arranque del sistema.

Activación y verificación:

sudo systemctl daemon-reload
sudo systemctl enable backup.timer
sudo systemctl start backup.timer
systemctl status backup.timer
systemctl list-timers --all

[WARNING] No olvides habilitar el timer, no el servicio. El timer se encargará de iniciar el servicio automáticamente. Si habilitas el servicio, se ejecutará en cada arranque, anulando el propósito del timer.

Logs con Journald: El Corazón de la Depuración

Systemd incluye journald, un demonio que recolecta y almacena todos los logs del sistema en un formato binario estructurado. A diferencia de los archivos de texto plano de syslog, journald ofrece búsquedas rápidas, metadatos ricos (PID, UID, prioridad, código de error) y rotación automática.

Configuración de Journald

El archivo de configuración principal es /etc/systemd/journald.conf. Algunas opciones clave:

[Journal]
Storage=auto          # auto: guarda en /var/log/journal si existe, sino en /run/log/journal (volátil)
SystemMaxUse=500M     # Tamaño máximo que puede ocupar el log del sistema
SystemKeepFree=100M   # Espacio libre que debe quedar en la partición
Compress=yes          # Comprime logs antiguos
ForwardToSyslog=yes   # Envía logs también a syslog tradicional (opcional)

Dominando journalctl

journalctl es la navaja suiza para consultar logs. Aquí tienes los usos más potentes:

• Ver logs en tiempo real: journalctl -f (similar a tail -f).
• Filtrar por unidad: journalctl -u nginx.service (logs de Nginx).
• Filtrar por prioridad: journalctl -p err -b (errores desde el último arranque). Prioridades: emerg, alert, crit, err, warning, notice, info, debug.
• Filtrar por tiempo:
  • journalctl --since "1 hour ago"
  • journalctl --until "2023-12-01 12:00"
  • journalctl --since yesterday
• Filtrar por PID: journalctl _PID=1234
• Ver logs del arranque actual: journalctl -b
• Ver logs de un arranque específico: journalctl --list-boots (lista arranques), luego journalctl -b -1 (penúltimo).
• Filtrar por campos específicos: journalctl _SYSTEMD_UNIT=sshd.service _UID=1000 (logs de SSH del usuario con UID 1000).
• Formato JSON: journalctl -o json-pretty (ideal para procesamiento automático).

Ejemplo de Depuración con Journald

Imagina que un servicio llamado miapp.service falla al iniciar. En lugar de buscar en archivos dispersos, ejecutas:

journalctl -u miapp.service --since "5 minutes ago" -p err

Esto te mostrará solo los errores de los últimos 5 minutos. Si ves mensajes como ExecStart=/usr/bin/fakeapp: No such file or directory, sabrás que el binario no existe. Si ves Permission denied, será un problema de usuario o permisos.

[INFO] Para ver logs de un servicio en tiempo real mientras lo depuras, abre dos terminales: una con journalctl -u miapp.service -f y otra para reiniciar el servicio con systemctl restart miapp.service.

Integración Completa: Un Ejemplo Real

Supongamos que necesitas un sistema que:

1. Ejecute un script de limpieza de logs cada 6 horas.
2. Si el script falla, se reinicie automáticamente hasta 3 veces.
3. Los logs del script se almacenen en journald.
4. El timer tenga un retardo aleatorio para no saturar el disco a la misma hora.

Paso 1: Script de limpieza (/usr/local/bin/clean-logs.sh):

#!/bin/bash
find /var/log -name "*.log" -mtime +7 -delete

Paso 2: Servicio (/etc/systemd/system/clean-logs.service):

[Unit]
Description=Limpieza de logs antiguos
After=local-fs.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/clean-logs.sh
Restart=on-failure
RestartSec=30
StartLimitBurst=3
StandardOutput=journal
StandardError=journal

Paso 3: Timer (/etc/systemd/system/clean-logs.timer):

[Unit]
Description=Ejecuta limpieza de logs cada 6 horas
Requires=clean-logs.service

[Timer]
OnCalendar=*:0/6
Persistent=true
RandomizedDelaySec=15min

[Install]
WantedBy=timers.target

Paso 4: Activación:

sudo systemctl daemon-reload
sudo systemctl enable --now clean-logs.timer

Con --now, inicias y habilitas el timer en un solo paso.

Buenas Prácticas y Consejos Avanzados

1. Nombres de unidades: Usa nombres descriptivos y evita espacios. Ej: backup-db.service.
2. Documentación: Siempre incluye Documentation=https://... en la sección [Unit].
3. Seguridad:
   • Usa User= y Group= para ejecutar servicios con mínimos privilegios.
   • Considera ProtectSystem=strict, PrivateTmp=true, NoNewPrivileges=true para servicios críticos.
4. Dependencias:
   • Requires= vs Wants=: El primero detiene el servicio si la dependencia falla; el segundo solo lo intenta.
   • Before= y After=: Controlan el orden de inicio.
5. Logs rotados: Aunque journald gestiona la rotación, puedes limitar el tamaño con SystemMaxUse=1G en journald.conf. Para logs de aplicaciones, usa StandardOutput=journal en lugar de archivos propios.
6. Reinicios inteligentes: Usa RestartPreventExitStatus=1 para evitar reiniciar si el servicio termina con código de salida específico (ej: 1 para error de configuración).
7. Monitoreo de timers: systemctl list-timers --all te muestra el próximo disparo y el último. Usa --no-pager para salida en scripts.

Conclusión

Systemd ha revolucionado la administración de sistemas Linux, ofreciendo un ecosistema cohesivo para servicios, temporizadores y logs. Dominar los unit files de servicio te permite desplegar aplicaciones de forma predecible y segura. Los timers superan a cron en flexibilidad y control, especialmente en entornos donde la persistencia y la tolerancia a fallos son críticas. Y journald, con su potente journalctl, convierte la depuración de logs en una tarea rápida y precisa, eliminando la necesidad de buscar en múltiples archivos.

Como SysAdmin, tu flujo de trabajo diario se beneficiará enormemente de estas herramientas. Desde la creación de un servicio simple hasta la automatización de tareas complejas con timers y la resolución de incidentes con logs estructurados, systemd te proporciona un control total sobre tu infraestructura. No dudes en experimentar con las