El proyecto systemd ha lanzado la versión 260, marcando un cambio importante en la evolución del sistema de inicio más utilizado en Linux: la eliminación del soporte para scripts heredados de SysV init. Esta decisión forma parte de una limpieza técnica profunda orientada a simplificar el código base, mejorar la mantenibilidad y alinearse con estándares modernos de gestión de servicios.
Para administradores de sistemas y entornos productivos, este cambio no es menor y requiere evaluación, especialmente en infraestructuras legacy.
Fin del soporte para SysV init: qué significa realmente
Hasta ahora, systemd mantenía compatibilidad con scripts de inicio estilo SysV (/etc/init.d/), permitiendo ejecutar servicios legacy mediante un mecanismo de compatibilidad.
Con systemd 260:
-
Se elimina completamente el soporte para scripts SysV init
-
Desaparece la capa de compatibilidad (systemd-sysv-generator)
-
Los servicios deben definirse exclusivamente mediante unidades systemd (.service)
👉 En términos prácticos:
Cualquier servicio que dependa de scripts antiguos dejará de funcionar si no se migra correctamente.
¿Por qué systemd toma esta decisión?
El soporte a SysV init llevaba años siendo considerado obsoleto. Las razones principales para su eliminación son:
✔ Simplificación del código
Reducir complejidad interna y eliminar código legacy difícil de mantener.
✔ Mejor rendimiento
Menos capas de compatibilidad implican:
-
Arranque más rápido
-
Menor consumo de recursos
-
Menos puntos de fallo
✔ Alineación con estándares modernos
Systemd ya domina el ecosistema Linux, y mantener compatibilidad con SysV init dejó de tener sentido práctico.
Impacto en administradores y entornos productivos
Este cambio afecta principalmente a:
🔴 Sistemas legacy
-
Scripts personalizados en /etc/init.d/
-
Software antiguo sin soporte nativo para systemd
-
Aplicaciones internas no actualizadas
🟡 Distribuciones modernas
En la mayoría de los casos, el impacto será mínimo, ya que:
-
Las distribuciones actuales usan unidades systemd
-
SysV init se mantenía solo por compatibilidad
Cómo identificar si tu sistema depende de SysV init
Podés verificar rápidamente si aún tenés servicios legacy:
ls /etc/init.d/
Y también detectar servicios no nativos:
systemctl list-unit-files | grep generated
Si aparecen servicios “generated”, probablemente estén usando compatibilidad SysV.
Migración de scripts SysV a systemd (paso a paso)
1. Identificar el servicio legacy
Ejemplo:
/etc/init.d/mi-servicio
2. Crear una unidad systemd
Archivo:
/etc/systemd/system/mi-servicio.service
Ejemplo básico:
[Unit] Description=Mi Servicio Legacy After=network.target [Service] Type=forking ExecStart=/etc/init.d/mi-servicio start ExecStop=/etc/init.d/mi-servicio stop Restart=always [Install] WantedBy=multi-user.target
3. Recargar systemd
systemctl daemon-reexec systemctl daemon-reload
4. Habilitar y probar
systemctl enable mi-servicio systemctl start mi-servicio systemctl status mi-servicio
⚠ Recomendación avanzada
Siempre que sea posible:
-
Evitar wrappers sobre scripts init.d
-
Reescribir servicios directamente como unidades systemd nativas
Ejemplo moderno:
[Service] ExecStart=/usr/bin/mi-binario --flag Restart=on-failure
Esto mejora:
-
Observabilidad (journalctl)
-
Control de dependencias
-
Manejo de fallos
Otras mejoras destacadas en systemd 260
Además de eliminar SysV init, systemd 260 incluye:
-
Mejoras en gestión de recursos (cgroups v2)
-
Optimización en tiempos de arranque
-
Mejor integración con contenedores
-
Refinamientos en logs y journal
Compatibilidad con distribuciones
systemd 260 comenzará a aparecer en:
-
Arch Linux (rápidamente)
-
Fedora (próximas versiones)
-
openSUSE Tumbleweed
-
Otras rolling releases
Distribuciones LTS tardarán más en adoptar este cambio.
Conclusión
La eliminación del soporte para SysV init en systemd 260 marca el cierre definitivo de una era en Linux. Aunque puede representar un desafío en entornos legacy, también es una oportunidad para modernizar la infraestructura y adoptar prácticas más robustas.
Si administrás sistemas Linux en producción, la recomendación es clara: auditar servicios legacy cuanto antes y planificar la migración a unidades systemd nativas. Postergar este cambio puede derivar en fallos críticos cuando las distribuciones adopten esta versión.
