Systemd vs Init: Gestión de Servicios en Linux 2025

La transición del clásico init System V a systemd ha sido una de las revoluciones silenciosas más profundas en el ecosistema Linux. Si eres sysadmin, saber cómo funciona la gestión de servicios en tu sistema no es opcional: es la columna vertebral de la operativa diaria. En este artículo, exploraremos a fondo las diferencias, ventajas, desventajas y casos de uso de ambos sistemas, con un enfoque práctico para 2025.

¿Qué es Init? El Origen de la Gestión de Servicios

El término init se refiere al primer proceso que arranca el kernel de Linux (PID 1). Durante décadas, el estándar fue System V init (sysvinit), caracterizado por su simplicidad y previsibilidad.

Cómo funciona sysvinit

Scripts shell secuenciales: Cada servicio tenía un script en /etc/init.d/.
Niveles de ejecución (runlevels): 0 (halt), 1 (single-user), 3 (multiusuario con red), 5 (multiusuario con GUI), 6 (reboot).
Dependencias manuales: Se gestionaban mediante enlaces simbólicos en /etc/rc?.d/ (S = start, K = kill).
Arranque lineal: Los servicios se iniciaban uno tras otro, sin paralelismo real.

[INFO] Aunque sysvinit es robusto, su arranque secuencial lo hacía lento en sistemas modernos con múltiples servicios. En un servidor con 50 servicios, el arranque podía tardar más de 2 minutos.

Ventajas de sysvinit

Simplicidad: Cualquier script shell es un servicio.
Depuración directa: Puedes ejecutar manualmente /etc/init.d/servicio start y ver la salida.
Sin sobrecarga: No requiere binarios adicionales para gestionar dependencias.

Desventajas evidentes

Arranque lento: Sin paralelismo.
Gestión de dependencias frágil: Un error en un script rompe la cadena.
Sin monitoreo: Si un servicio muere, no se reinicia automáticamente.

Systemd: La Revolución del PID 1

Systemd (system daemon) nació en 2010 de la mano de Lennart Poettering y Kay Sievers. Hoy, es el sistema de init predeterminado en prácticamente todas las distribuciones Linux modernas (Fedora, Ubuntu, Debian, Arch, RHEL, etc.).

Principios fundamentales

Paralelización agresiva: Aprovecha sockets y D-Bus para iniciar servicios en cuanto sus dependencias están listas, sin esperar a que otros terminen.
Gestión de dependencias real: Las unidades declaran explícitamente Requires, Wants, After y Before.
Monitoreo y reinicio automático: Systemd puede reiniciar servicios caídos, limitar su tasa de reinicios y registrar fallos.
Unificación: No solo gestiona servicios, también montajes, dispositivos, temporizadores, sockets y targets (reemplazo de runlevels).

Arquitectura de unidades

Systemd organiza todo en unidades (units). Cada unidad es un archivo de configuración (.service, .socket, .target, .timer, etc.).

# Ejemplo de unidad de servicio (/etc/systemd/system/mi-servicio.service)
[Unit]
Description=Mi servicio personalizado
After=network.target

[Service]
ExecStart=/usr/local/bin/mi-app
Restart=on-failure
RestartSec=5
User=mi-usuario

[Install]
WantedBy=multi-user.target

[TIP] Siempre usa systemctl daemon-reload después de modificar o crear una unidad. Olvidarlo es el error #1 de los novatos.

Comandos esenciales para sysadmin

# Gestión de servicios
systemctl start servicio.service
systemctl stop servicio.service
systemctl restart servicio.service
systemctl status servicio.service

# Habilitar/deshabilitar en arranque
systemctl enable servicio.service
systemctl disable servicio.service

# Análisis de arranque
systemd-analyze blame        # Servicios que más tardan
systemd-analyze critical-chain  # Cadena crítica de arranque
systemd-analyze plot > boot.svg  # Gráfico visual del arranque

# Gestión de logs (journald)
journalctl -u servicio.service   # Logs del servicio
journalctl -f                    # Sigue los logs en tiempo real

Comparativa Directa: Systemd vs Init

Característica	System V Init	Systemd
Velocidad de arranque	Lento (secuencial)	Rápido (paralelo)
Gestión de dependencias	Manual (enlaces simbólicos)	Automática (directivas en unidad)
Reinicio automático	No	Sí (Restart=)
Logging	Archivos de texto separados	Journald centralizado
Aislamiento	No	Sí (cgroups, namespaces)
Compatibilidad con scripts	Total	Parcial (necesita wrapper)
Curva de aprendizaje	Baja	Media-alta

Rendimiento en boot Linux 2025

En hardware moderno (SSD NVMe, CPU multi-core), systemd puede reducir el tiempo de arranque de un servidor típico de 90 segundos (sysvinit) a menos de 15 segundos. La paralelización y el uso de sockets activables por demanda son los responsables.

# Ejemplo: tiempo de arranque medido con systemd-analyze
$ systemd-analyze
Startup finished in 2.345s (kernel) + 8.123s (init) = 10.468s

Gestión de Servicios Linux: Casos Prácticos

Escenario 1: Servicio web con reinicio automático

Con sysvinit, tenías que escribir un script complejo con watchdog. Con systemd:

# /etc/systemd/system/mi-web.service
[Unit]
Description=Servidor web personalizado
After=network.target postgresql.service

[Service]
ExecStart=/usr/local/bin/mi-web-server
Restart=always
RestartSec=10
User=www-data
Group=www-data
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Escenario 2: Temporizadores (reemplazo de cron)

Systemd incluye temporizadores que son más potentes y tienen mejor logging que cron.

# /etc/systemd/system/mi-backup.timer
[Unit]
Description=Ejecutar backup diario

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

# /etc/systemd/system/mi-backup.service
[Unit]
Description=Script de backup

[Service]
ExecStart=/usr/local/bin/backup.sh
Type=oneshot

[WARNING] Los temporizadores no reemplazan completamente a cron si necesitas sintaxis muy específica o variables de entorno heredadas. Siempre prueba con systemctl start mi-backup.timer y verifica con journalctl -u mi-backup.service.

Escenario 3: Aislamiento de servicios con cgroups

Systemd usa control groups (cgroups) para limitar recursos por servicio. Esto es crucial en entornos multiinquilino.

# /etc/systemd/system/mi-servicio.service
[Service]
MemoryMax=500M
CPUQuota=50%
IOWeight=100

Controversias y Críticas a Systemd

Systemd no está exento de polémica. Muchos sysadmins veteranos lo critican por:

Violación del principio Unix: "Haz una cosa y hazla bien". Systemd hace muchas cosas (init, logging, temporizadores, resolución de nombres, gestión de red...).
Complejidad: Una unidad mal configurada puede dejar el sistema inaccesible.
Dependencia binaria: Sin systemd, no puedes arrancar el sistema. Con sysvinit, podías sustituir init por otro (runit, openrc).
Logs binarios: Journald almacena logs en formato binario. Herramientas como less o grep no funcionan directamente (necesitas journalctl).

[INFO] Distribuciones como Devuan, Artix o Alpine Linux mantienen alternativas (OpenRC, runit) para quienes prefieren evitar systemd. Sin embargo, en 2025, systemd es el estándar de facto en el 95% de los servidores.

Migración de Init a Systemd: Guía Rápida

Si heredas un servidor antiguo con sysvinit, estos pasos te ayudarán a migrar:

Identificar servicios: ls /etc/init.d/ y chkconfig --list.
Crear unidades systemd: Para cada servicio, crea un archivo .service en /etc/systemd/system/.
Probar manualmente: systemctl start servicio.service.
Habilitar en arranque: systemctl enable servicio.service.
Deshabilitar el script init: chkconfig servicio off o eliminar enlaces en /etc/rc?.d/.
Verificar dependencias: Revisa After= y Requires= para mantener el orden correcto.

# Ejemplo de migración de Apache
# Antes (sysvinit)
/etc/init.d/httpd start

# Después (systemd)
systemctl start httpd.service
systemctl enable httpd.service

El Futuro de la Gestión de Servicios Linux en 2025

Systemd sigue evolucionando. Las versiones recientes (v250+) incluyen:

systemd-sysupdate: Actualizaciones atómicas del sistema.
systemd-repart: Reparticionado automático de discos.
systemd-oomd: Gestión proactiva de Out-Of-Memory.
Mejoras en seguridad: Sandboxing más estricto con ProtectSystem=, ProtectHome=, PrivateTmp=.

La tendencia es clara: systemd se está convirtiendo en una plataforma de gestión del sistema completa, no solo un init. Como sysadmin, dominar systemd te da control granular sobre cada aspecto del comportamiento del servidor.

Conclusión: ¿Qué Elegir en 2025?

Para un sysadmin moderno, la respuesta es clara: systemd. Ofrece velocidad, robustez, monitoreo integrado y herramientas de análisis que sysvinit simplemente no puede igualar. Sin embargo, entender sysvinit sigue siendo valioso para mantener sistemas legacy o para comprender los fundamentos de la gestión de servicios.

Si trabajas en entornos de alta disponibilidad, contenedores (Docker/Podman) o infraestructura cloud, systemd es tu mejor aliado. Su capacidad para aislar servicios con cgroups, reiniciar procesos fallidos y centralizar logs te ahorrará horas de depuración.

[TIP] No te obsesiones con la controversia. Aprende ambos sistemas, pero enfócate en systemd para el día a día. En 2025, es la herramienta que todo sysadmin debe dominar.

Recuerda: La gestión de servicios Linux es la base de la fiabilidad de tu infraestructura. Ya sea con systemd o init, el conocimiento profundo de cómo arranca y se mantiene tu sistema es lo que diferencia a un administrador de sistemas promedio de un experto.