A menos que hayas estado viviendo bajo una roca, o peor aún – que no te importe mucho cómo funciona Linux, debes haber oído hablar de systemd, el (relativamente) nuevo sistema de init que reemplaza al viejo y anticuado SysV init recientemente adoptado por la mayoría de las principales distros de Linux.

¿Qué es un sistema init?

Cuando tu máquina Linux arranca, primero ejecutará algún código “incorporado”, cargado desde la BIOS o UEFI primero, seguido por el cargador de arranque, que según su configuración carga un kernel Linux. El kernel carga los controladores y, como primera tarea, inicia el proceso init, que al ser el primero tiene asignado el PID (Process ID) 1.

Desde el punto de vista del usuario, esto parece el inicio de la red y las bases de datos, etc., pero en realidad hay un proceso bastante complejo que tiene lugar bajo el capó. Los servicios se inician, se detienen y se reinician, a menudo en paralelo. Algunos se ejecutan con privilegios diferentes a los de otros, se informa y registra el estado de los servicios y se realizan muchas otras tareas que harán que las diferentes partes del sistema funcionen y puedan interactuar con sus usuarios y su entorno.

Sin embargo, la forma en que esto se implementa dista mucho de ser uniforme, y aquí es donde realmente todo deja de ser común y bien definido.

El antiguo sistema de inicio

El sistema de init utilizado por la mayoría de las distribuciones de Linux hasta hace poco tiempo era el System V init (o SysV init, para abreviar), que ha derivado su nombre del Sistema V de UNIX (pronunciado “System Five”), el primer sistema UNIX disponible comercialmente. El sistema operativo System V ha tenido una forma específica de ejecutar su proceso de init, y SysV init se ha mantenido fiel a esto a lo largo de los años.

Y han sido muchos años. El Sistema V de UNIX fue lanzado originalmente en 1983, lo que hace que el SysV init sea un enfoque de más de 30 años para el arranque de máquinas Linux.

La necesidad de un cambio

Como se ha observado, el SysV init se ha quedado anticuado y hace tiempo que debería haber sido reemplazado. Algunas de las razones para ello son

• SysV init utiliza /sbin/init para iniciar el proceso de init, pero el propio init tiene un papel muy limitado. init hace poco más que iniciar /etc/init.d/rc, según la configuración leída de /etc/inittab, que a su vez ejecutará scripts para hacer el verdadero trabajo del proceso de init. Esto, a no ser que se panelice explícitamente (como con startpar en Debian), ocurrirá de forma secuencial, iniciándose un script tras otro, haciendo que todo el proceso sea lento ya que cada script tiene que esperar a que el anterior termine.
• SysV init no tiene acceso al PID o a los procesos que ha iniciado (indirectamente). Sólo lee los PID y los asocia a los procesos reales de forma circunstancial y complicada.
• Para los administradores de sistemas que intentan modificar el entorno bajo el cual se iniciaría un determinado proceso, es bastante difícil con SysV init. (Para lograrlo tendrán que modificar el strcipt init que es responsable de iniciar el proceso dado).
• Hay ciertas funcionalidades comunes a todos los servicios que SysV no implementa, pero que cada proceso tendría que implementar por sí mismo en su lugar, como por ejemplo “daemonizarse” (convertirse en un demonio del sistema), lo cual es un proceso elaborado y largo. En lugar de implementar estos pasos una vez, SysV requiere que cada proceso haga el trabajo por sí mismo.
• SysV también deja ciertas funcionalidades a programas externos y no sabe nada de los servicios iniciados por éstos.

Todo lo anterior, y muchos más defectos de diseño, o mejor dicho, el diseño anticuado del sistema SysV, ha hecho que la creación de un sistema init moderno sea algo muy esperado.

Entra systemd

Hubo muchos intentos de crear un sistema de inicio alternativo, de los cuales systemd es sólo uno de ellos. Ubuntu solía ejecutar su propio sistema de inicio llamado upstart. Gentoo todavía utiliza 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 fueron por el camino de systemd, ya que Fedora fue la primera distro en adoptar oficialmente systemd en 2011. Pero systemd se ha convertido realmente en el único sistema init que los gobierna a todos, cuando Debian 8 cambió oficialmente a systemd, trayendo a Ubuntu y derivados con él, superando la oposición inicial de Canonical (o más precisamente de Mark Shuttleworth) hacia systemd.

¿En qué se diferencia systemd?

• El objetivo de Systemd es proporcionar una forma única y centralizada de manejar el proceso de init de principio a fin.
• Inicia y detiene procesos y servicios mientras mantiene un seguimiento de sus dependencias. Incluso puede iniciar un proceso como respuesta a la necesidad 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á en marcha en respuesta a ciertos eventos de activación, como cuando se conecta un dispositivo.
• Tampoco requiere que los procesos se demonicen a sí mismos. A diferencia de SysV init, systemd puede manejar servicios en ejecución sin tener que pasar por el largo proceso de convertirse en demonios.
• A diferencia de SysV init, systemd conoce y rastrea todos los procesos, incluyendo los PIDs, y obtener información sobre los procesos es mucho más sencillo para los administradores del sistema bajo systemd.
• Systemd soporta contenedores que son básicamente entornos de servicio aislados sin el requisito de las máquinas virtuales. Esto tiene un gran potencial hacia diseños de sistemas más seguros y sencillos en el futuro.

Por supuesto, éstas 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” de Debian 8

Controversia

Por supuesto, systemd no fue bien recibido por todos. De hecho, muchos lo han visto y lo siguen viendo con malos ojos, calificándolo de monolítico y engorroso, algunos incluso lo acusan de seguir el “camino de Windows” de tener todo centralizado. Muchos argumentan que no es “el camino de Linux”, y ciertamente systemd no parece estar de acuerdo con los estándares POSIX, y si consideramos systemd como un conjunto de herramientas (más allá de sólo el 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 abordadas por su autor y desarrollador original Lennart Poettering. Definitivamente es un avance muy necesario y un paso adelante respecto al antiguo sistema de inicio. A Linus Torvalds, el creador de Linux, no parece importarle demasiado systemd, y quiénes somos nosotros para discutir con “El Creador”.

Conclusión

Habiendo sido adoptado por todas las principales distribuciones de Linux, systemd está aquí para quedarse. Digan 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 cual, viendo sus distintas 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 podrán ser más “compatibles” entre sí. En cuanto a los usuarios, definitivamente nos beneficiaremos del diseño de sistema más actualizado y contemporáneo que aporta a nuestros escritorios.