A menos que hayas estado viviendo bajo una roca, o peor – no te importa mucho cómo funciona Linux, debes haber oído hablar de systemd , el (relativamente) nuevo sistema init que reemplaza al viejo y anticuado SysV init recientemente adoptado por la mayoría de las grandes distribuciones Linux.
¿Qué es un sistema init?
Cuando su máquina Linux se inicia, primero ejecutará algún código «incorporado», cargado primero desde la BIOS o UEFI, seguido por el cargador de arranque, que según su configuración carga un kernel de Linux. El kernel carga los controladores, y como su primer trabajo inicia el proceso init, que es el primero al que se le asigna el PID (Process ID) 1.
Desde el punto de vista del usuario, parece que se está iniciando una red, una base de datos, etc., pero en realidad se está llevando a cabo un proceso bastante complejo. Los servicios se inician, se detienen y se reinician, a menudo en paralelo. Algunos se ejecutan bajo privilegios diferentes a otros, los estados de los servicios se reportan y registran, y se realizan muchas otras tareas que harán que la parte diferente de su sistema funcione y pueda interactuar con sus usuarios y su entorno.
Sin embargo, la forma en que esto se aplica dista mucho de ser uniforme, y aquí es donde todo deja de ser común y bien definido.
El antiguo sistema init
El sistema init utilizado por la mayoría de las distribuciones Linux más comunes hasta hace poco era System V init (o SysV init en pocas palabras), que ha derivado su forma de nombre UNIX System V (Se pronuncia «System Five»), el primer sistema UNIX disponible comercialmente. System V OS ha tenido una forma específica de ejecutar su proceso init, y SysV init se ha mantenido leal a esto a lo largo de los años.
Y han pasado muchos años. UNIX System V fue lanzado originalmente en 1983, convirtiendo al init SysV init en un enfoque de más de 30 años de antigüedad para el arranque de máquinas Linux.
La necesidad de un cambio
Como se ha señalado, SysV init ha quedado obsoleto y hace tiempo que debería haberse sustituido. Algunas de las razones de esto incluyen:
- SysV init utiliza /sbin/init para iniciar el proceso init, pero init en sí mismo tiene un papel muy limitado. init hace poco más que iniciar /etc/init.d/rc, de acuerdo con la configuración leída de /etc/inittab, que a su vez ejecutará scripts para hacer el trabajo real del proceso init. Esto, a menos que se panelice explícitamente (como con startpar en Debian), ocurrirá secuencialmente, un script comenzando uno tras otro, haciendo que todo el proceso sea lento ya que cada script tiene que esperar a que termine el anterior.
- SysV init no tiene acceso al PID ni a los procesos que ha iniciado (indirectamente). Sólo lee los PIDs y los asocia con procesos reales de una manera circunstancial y complicada.
- Para los administradores de sistemas que intentan modificar el entorno en el que se iniciaría un determinado proceso, es bastante difícil con init de SysV (para ello tendrán que modificar la estrategia de init que es la responsable de iniciar el proceso en cuestión).
- Hay ciertas funcionalidades comunes a todos los servicios que SysV no implementa, pero cada proceso tendría que implementarse a sí mismo, como por ejemplo «daemonizarse» a sí mismo (convertirse en un demonio del sistema), que es un proceso laborioso y largo . En lugar de implementar estos pasos una sola vez, SysV requiere que cada proceso haga el trabajo por sí mismo.
- SysV también deja cierta funcionalidad a programas externos y no sabe nada sobre los servicios iniciados por ellos.
Todo lo anterior, y muchos más defectos de diseño, o mejor dicho, el anticuado diseño del sistema de SysV, ha hecho que la creación de un moderno sistema init se haya retrasado mucho tiempo.
Entrar en systemd
Hubo muchos intentos de crear un sistema init alternativo, del cual systemd es sólo uno de ellos. Ubuntu solía ejecutar su propio sistema init llamado upstart . Gentoo sigue usando OpenRC . Otros sistemas de init incluyen initng , busybox-init , runit , y Mudur y otros.
La razón por la que systemd es un claro ganador es que ha sido adoptado por la mayoría de las principales distribuciones. RHL y CentOS naturalmente siguieron el camino del sistema, ya que Fedora fue la primera distribución en adoptar oficialmente systemd en 2011. Pero systemd se ha convertido realmente en el único sistema que los gobierna a todos, cuando Debian 8 cambió oficialmente a systemd, trayendo consigo Ubuntu y sus derivados, superando la oposición inicial de Canonical (o más precisamente la de Mark Shuttleworth) hacia systemd.
¿En qué se diferencia systemd?
- El objetivo de Systemd es proporcionar una forma única y centralizada de gestionar el proceso de inicio de principio a fin.
- Inicia y detiene los procesos y servicios mientras hace un seguimiento de sus dependencias. Incluso puede iniciar un proceso como respuesta a un requisito de dependencia de otro proceso.
- Además de iniciar y detener procesos durante el tiempo de arranque, Systemd también puede iniciarse en cualquier momento cuando el sistema está encendido en respuesta a ciertos eventos de disparo, como cuando un dispositivo está conectado.
- Tampoco requiere procesos para demonizarse a sí mismos. A diferencia de SysV init, systemd puede manejar servicios que se ejecutan sin tener que pasar por el largo proceso de convertirse en demonios.
- A diferencia de SysV init, systemd conoce y realiza un seguimiento de todos los procesos, incluidos los PID, y obtener información sobre los procesos es mucho más sencillo para los administradores de sistemas en systemd.
- Systemd soporta contenedores que son básicamente entornos de servicio aislados sin el requerimiento de máquinas virtuales. Esto tiene un gran potencial para diseñar sistemas más seguros y sencillos en el futuro.
Por supuesto, estas son sólo algunas de las principales ventajas. Para una discusión completa sobre las ventajas de systemd, debería leer la «Declaración de posición de Systemd «
Controversia
Por supuesto, systemd no fue bien recibido por todos. De hecho, muchos tienen y siguen teniendo frunciendo el ceño , llamándolo monolítico y engorroso, algunos incluso lo acusan de ir por el «camino de las ventanas» de tenerlo todo centralizado. Muchos argumentan que no es «a la manera de Linux», y ciertamente systemd no parece estar de acuerdo con los estándares POSIX, y si consideramos systemd como un toolkit (más allá del binario), es definitivamente hugae.
Sin embargo, systemd es claramente un paso adelante, y aunque no es perfecto, muchas de las críticas que ha recibido han sido dirigidas por su autor original y el desarrollador Lennart Poettering. Definitivamente es un avance muy necesario y un paso por delante del antiguo sistema init. Linus Torvalds, el creador de Linux, no parece que le importe demasiado systemd , y quiénes somos nosotros para discutir con «El Creador.»
Conclusión
Al haber sido adoptado por todas las principales distribuciones de Linux, systemd está aquí para quedarse. Independientemente de lo que digan algunos administradores de sistemas por la razón que sea, systemd es el futuro de la corriente principal de Linux, les guste o no a los usuarios individuales, lo que, teniendo en cuenta sus claras ventajas, no es necesariamente algo malo.
Para el usuario medio aporta tiempos de arranque más rápidos y probablemente sistemas más fiables, mientras que en el futuro las distribuciones que lo adopten pueden llegar a ser más «compatibles» entre sí. En cuanto al usuario, nos beneficiaremos definitivamente del diseño de sistemas más actualizado y contemporáneo que aporta a nuestros ordenadores de sobremesa.
