Systemd – Lo que necesitas saber

A menos que hayas estado viviendo bajo una roca, o peor – que no te importe mucho cómo funciona Linux, seguramente has oído hablar de systemd, el sistema init (relativamente) nuevo que reemplaza al antiguo y obsoleto SysV init, adoptado recientemente por la mayoría de las principales distribuciones de Linux.

¿Qué es un sistema init?

Cuando tu máquina Linux arranca, primero ejecutará algún código “integrado”, cargado desde el BIOS o UEFI, seguido por el cargador de arranque, que según su configuración carga un núcleo de Linux. El núcleo carga los controladores y, como su primer trabajo, inicia el proceso init, que siendo el primero, recibe el PID (Identificador de Proceso) 1 asignado.

Desde el punto de vista del usuario, esto parece como iniciar la red, bases de datos, etc., pero en realidad hay un proceso bastante complejo que ocurre en segundo plano. Los servicios se inician, detienen y reinician, a menudo en paralelo. Algunos se ejecutan con privilegios diferentes a otros, se informan y registran los estados de los servicios, y se realizan muchas otras tareas que permiten que las diferentes partes de tu sistema funcionen e interactúen con sus usuarios y su entorno.

Sin embargo, cómo se implementa esto está lejos de ser uniforme, y ahí 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 populares hasta hace poco era el System V init (o SysV init en corto), que deriva su nombre del UNIX System V (pronunciado “Sistema Cinco”), el primer sistema UNIX disponible comercialmente. El sistema operativo System V ha tenido una forma específica de ejecutar su proceso init, y SysV init ha mantenido lealtad a esto a lo largo de los años.

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

La necesidad de un cambio

Como se ha señalado, SysV init ha quedado obsoleto y ha pasado mucho tiempo desde que debía ser reemplazado. Algunas de las razones para esto incluyen:

• SysV init usa /sbin/init para iniciar el proceso init, pero init en sí 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 trabajo real del proceso init. Esto, a menos que se paralelice explícitamente (como con startpar en Debian), sucederá secuencialmente, un script comenzando después del otro, haciendo que todo el proceso sea lento, ya que cada script tiene que esperar que el anterior termine.
• SysV init no tiene acceso a los PID o los procesos que ha (indirectamente) iniciado. Solo lee los PIDs y los asocia con procesos reales de una manera circunstancial y complicada.
• Para los administradores del sistema que intentan modificar el entorno bajo el cual un cierto proceso comenzaría, es bastante difícil con SysV init. (Para lograr esto, tendrán que modificar el script init que es responsable de iniciar el proceso dado.)
• Hay cierta funcionalidad común a cada servicio que SysV no implementa, pero cada proceso tendría que implementarse a sí mismo, como “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 cierta funcionalidad a programas externos y no sabe nada sobre los servicios iniciados por esos.

Todo lo anterior, y muchos más defectos de diseño, o más bien el diseño de sistema obsoleto de SysV, han hecho que la creación de un sistema init moderno sea muy urgente.

Entra systemd

Hubo muchos intentos de crear un sistema init alternativo, de los cuales systemd es solo uno de ellos. Ubuntu solía ejecutar su propio sistema init llamado upstart. Gentoo todavía usa OpenRC. Otros sistemas init incluyen initng, busybox-init, runit, 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 adoptaron el camino de systemd, ya que Fedora fue la primera distribución 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, llevando a Ubuntu y sus derivados con él, superando la oposición inicial de Canonical (o más precisamente de Mark Shuttleworth) hacia systemd.

¿Cómo es systemd diferente?

• Systemd busca proporcionar una forma única y centralizada de manejar el proceso 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 iniciar en cualquier momento cuando el sistema esté activo en respuesta a ciertos eventos desencadenantes, como cuando se conecta un dispositivo.
• También no requiere que los procesos se daemonizen. 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, incluidos los PIDs, y obtener información sobre los procesos es mucho más simple para los administradores del sistema bajo systemd.
• Systemd admite contenedores que son básicamente entornos de servicio aislados sin la necesidad de máquinas virtuales. Esto tiene un gran potencial para diseños de sistemas más seguros y simples en el futuro.

Por supuesto, estas son solo algunas de las principales ventajas. Para una discusión completa sobre las ventajas de systemd, deberías 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 han y aún lo hacen despotricar sobre él, llamándolo monolítico y engorroso, algunos incluso acusándolo de seguir el “camino de Windows” por tener todo centralizado. Muchos argumentan que no es “el camino de Linux”, y ciertamente systemd no parece estar en conformidad con los estándares POSIX, y si consideramos systemd como un conjunto de herramientas (más allá de solo el binario), definitivamente es enorme.

Sin embargo, systemd es claramente un paso adelante, y aunque no es perfecto, gran parte de la crítica que ha recibido ha sido abordada por su autor y desarrollador original Lennart Poettering. Definitivamente es un avance muy necesario y un paso adelante respecto al antiguo sistema init. Linus Torvalds, el creador de Linux, no parece preocuparse demasiado por systemd, y quiénes somos nosotros para discutir con “El Creador”.

Conclusión

Habiendo sido adoptado por todas las principales distribuciones de Linux, systemd ha venido para quedarse. Lo que algunos administradores del sistema digan por cualquiera sea la razón, systemd es el futuro del Linux mainstream, le guste o no a los usuarios individuales, lo cual, observando sus claras ventajas, no es necesariamente una cosa mala.

Para el usuario promedio, trae tiempos de arranque más rápidos y probablemente sistemas más fiables, mientras que en el futuro las distribuciones que lo adopten pueden volverse más “compatibles” entre sí. En el extremo del usuario definitivamente nos beneficiaremos del diseño de sistema más actualizado y contemporáneo que trae a nuestros escritorios.