Lennart_poettering_SystemD

¿Porqué SystemD es el demonio?

SystemD es un sistema de inicio del kernel (a lo que se le suele conocer como init en entornos Unix, como Linux). Fue creado por Lennart Poettering (quien es su máximo valedor) y Kay Sievers trabajando para Red Hat, y tiene licencia LGPL 2.1 (con excepciones licenciadas con GPL 2). Está disponibe en GitHub.

Es un programa que genera una inmensa polémica, del que se está oyendo hablar cada vez más y que es utilizado por la mayoría de distribuciones. Sus detractores son muchos, sin embargo es utilizado cada vez por más distribuciones Linux. Así que surgen las preguntas. ¿Porqué SystemD es tan malo? Y si es tan malo, ¿porqué cada vez más distribuciones lo están utilizando?

Partiendo de que yo soy un total desconecedor de los sistemas de inicio, intentaré adentrarme en esta problemática para aprender un poco en el camino e intentar responder esas preguntas. Es un tema complejo, además, así que este artículo pretende ser una mera aproximación o introducción al tema para que todos podamos empezar a formarnos una idea sobre esta polémica.

Empezaremos comprobando qué es eso de un “sistema de inicio”. Seguiremos aprendiendo un poco de su desarrollo histórico, pues es el que ha llevado a la creación de SystemD. Después aprenderemos sobre sus características, ventajas y defectos o problemas. Pero primero, un par de aclaraciones:

 

 

Programas, procesos y demonios.

 

Siguiendo la recomendación de quien sí sabe bien del tema, vamos a distinguir varias cuestiones:

Un programa es un programa informático o programa de computadora es una secuencia de instrucciones, escritas para realizar una tarea específica en un ordenador.

Un proceso es una instancia en particular, dentro de un programa. En Linux llevan un identificador denominado PID (Process ID). En función del tipo de PID que lleve el proceso, tendrá ciertas características o bien tendrá otras. Un proceso también puede crear otros procesos; en esos casos, al proceso creador se le conoce como “proceso padre”, y a los procesos creados se les conoce como “procesos hijo”.

Un demonio o servicio es un tipo particular de proceso, que funciona en segundo plano (no es controlado directamente por el usuario).

 

 

El inicio y el final de todo.

El sistema de inicio o init, es un demonio especialmente importante en sistemas tipo UNIX. Es el primer proceso en cargarse y ejecutarse; e inicia el espacio de usuario. De él, nacen todos los demás procesos en ese espacio. Mantiene una tabla de procesos activos, lo que es necesario para el buen funcionamiento del sistema; y finalmente es el último proceso en finalizar, al apagar el sistema. Cuando termina init, termina el sistema.

Otra característica importante es que normalmente tiene PID 1. Como decíamos, PID es el identificador de proceso que define ciertas características del mismo. PID 1 se usa en muy pocos casos; permite controlar determinados demonios que se han desligado del proceso padre, pero por otro lado también implica que si el proceso con ID 1 termina, el sistema se cae.

 

 

Un poco de historia.

Tradicionalmente los demonios init han sido de dos tipos: estilo BSD y estilo System V. Ambos estilos lanzaban los servicios mediante una secuencia prefijada.

El estilo BSD establece un único scrip de inicialización en /etc/rc, que lanza todos los servicios. No hay niveles de ejecución (runlevels), el archivo /etc/rc determina qué programas se ejecutan por init. La ventaja de este sistema es que es simple y fácil de editar manualmente, aunque sujeto a errores. Era el estilo del UNIX original, y destacablemente sigue siendo utilizado por defecto en Slackware.

El estilo System V, en el que destaca SysVinit, funciona mediante runlevels, con diferentes scripts que establecen el estado (arranque/parada) de cada servicio en el directorio /etc/rc.d/. Era utilizado por muchas otras distribuciones, como Debian o Arch.

Debido al tiempo transcurrido desde la creación de esos estilos, ha surgido la necesidad de crear opciones más potentes y adaptadas a las necesidades y capacidades actuales de los kernel y sistemas operativos. Nombraremos en particular OpenRC, y Upstart.

OpenRC es el sistema de inicio por defecto en Gentoo (aunque también es admitido por otras distribuciones, como por ejemplo Arch Linux aunque sin soporte oficial). Este sistema de inicio es parcialmente compatible tanto con BSD como con SistemV, y está basado en dependencias (Gentoo también admite SystemD, si alguien prefiere utilizarlo). Una de sus ventajas sobre los anteriores sistemas, es que admite la paralelización de procesos; esto es, mientras que en los sistemas anteriores cada proceso era lanzado de forma secuencial, uno detrás de otro según cierto orden, en OpenRC es posible trabajar con más de un proceso a la vez. Como resultado, se consigue un ahorro de tiempo al inciar el sistema. Sin embargo, la paralelización puede causar problemas importantes, y OpenRC la admite de forma opcional hasta que sean solventados. Además, otras características a destacar son que OpenRC puede utilizarse con otros kernels además de Linux, y admite el manejo de procesos mediante cgroups (Control Groups), una característica que permite el kernel Linux. Veamos: a medida que un proceso (proceso “padre”) crea otro proceso (proceso “hijo”), y este a su vez crea un tercer proceso (proceso “nieto”), y este crea tal vez otro proceso más (proceso “bisnieto”); se va dificultando el control del primer proceso, respecto a los proceso más alejados. Esto puede dificultar, por ejemplo, la finalización de los procesos más alejados, quedando descolgados a su aire cuando el primer o el segundo proceso son finalizados (a esto se le conoce como “procesos zombies”). Cgroups soluciona este problema estableciendo grupos de procesos a los que se le asigna determinadas características, y en particular la característica “ser dependiente del proceso padre”). Entonces, si un proceso padre es finalizado, todos los procesos agrupados con él también son finalizados. Pero no sólo esa característica es asignable a un proceso, también son asignables muchas otras como por ejemplo el límite de memoria a utilizar.

Por su parte, Upstart fue creado por Canonical para Ubuntu (por lo que fue ampliamente utilizado por muchos usuarios). También fue adoptado por otras distribuciones, y constituyó tal vez el intento más importante para sustituir los antiguos init. Upstart tampoco lanzaba los servicios de forma prefijada, sino respondiendo a “eventos” previos. Esto le permite lanzar servicios de forma paralela, obteniendo la consiguiente ganancia de tiempo, aunque también implica el peligro de que determinados procesos se inicien ANTES de otros procesos que necesitan previamente. Para evitarlo, Upstart también incluye un sistema de dependencias entre los diferentes procesos. Sin embargo, como sabemos incluso Canonical ha abandonado Upstart para pasarse a SystemD.

 

 

Como funciona SystemD.

SystemD fue creado por Red Hat, como un sustituto más moderno de init. Entre sus ventajas podemos destacar que, al igual de Upstart, permite lanzar los servicios paralelamente. Pero a diferencia de la creación de Canonical, no necesita dependencias. En su lugar, crea sockets para cada servicio; esto significa que el servicio está precargado en memoria, pero no está activo. Los programas pueden incluso escribir en esos sockets, pero sin leerlos ni iniciarlos. Esos sockets sólo son leídos e iniciados cuando es necesario utilizar ese servicio en particular.

Otra ventaja de SystemD radica en su manejo de los puntos de montaje. Para iniciarse, algunos servicios necesitan que su punto de montaje estén efectivamente montado. SystemD, al igual que ocurre con la precarga en memoria de los servicios, pre-crea los puntos de montaje necesarios, pero sin llegar a montarlos realmente. A medida que cada servicio lo necesite, irá montándolos de verdad.

Otra característica de SystemD es que al igual que OpenRC, también utiliza los cgroups.

Por último destacaremos que SystemD define un sistema de “Units”. Son archivos de configuración de los recursos que el sistema conoce y puede emplear: servicios, puntos de montaje,el sistema de archivos, la swap, etc. Cada unit define características para ese recurso, permitiendo controlar el recurso de forma independiente a otros recursos. Este sistema es muy potente, y permite hacer muchísimas cosas, permitiendo sustituir o eliminar determinados programas o procesos del sistema o incluso de otros programas. Pero, justamente esto es algo que sus detractores no quieren que haga un simple init…

 

 

KISS: estúpido, simple y estable. (definición de lo que no es SystemD).

SystemD, que funciona con el kernel linux, no es UN demonio, sino un conjunto de VARIOS demonios , creados desde una perspectiva unificadora tanto del sistema operativo concreto como de las diversas distribuciones linux: su objetivo es, por una parte, establecer un administrador de sistema y de servicios; una plataforma de desarrollo de software, y una conexión entre las aplicaciones y el núcleo de Linux. Y por otra parte, eliminar diferencias entre las diversas distribuciones de GNU/Linux.

En esta oración, leemos varias aberraciones para las filosofías KISS, UNIX/Linux y de libertad que guían a buena parte de la comunidad. La filosofía KISS implica que un software debe ser lo más simple posible (en su propio funcionamiento), de tal forma que también será muy estable. Esto va en línea con la filosofía UNIX de que un software sirva para una única función. Y todo ello en un contexto de software libre con código abierto que otorguen al usuario libertad y control en sus propio sistema y software, pudiendo modificarlo y variarlo tanto como quiera o necesite, si es que tiene los conocimientos para hacerlo. Así que veamos con mayor detenimiento todos estos problemas, y las críticas que hacen los destractores de SystemD.

En primer lugar, SystemD funciona con el kernel Linux, y punto. No es compatible con otros kernels. Esto es algo negativo de por sí. Sin embargo, este nivel de dependencia respecto al kernel puede ser considerado el punto de partida para el control sobre todo el ecosistema GNU/Linux, y también tiene otras implicaciones: el nivel de unidad entre el kernel Linux y SystemD es tal que SystemD es incompatible con versiones diferentes del kernel. Así, por ejemplo SystemD está muy atado a funcionar con glibc , resultando incompatible con otras librerías.

SystemD no es simple ni cumple una única función. Es un programa muy complejo formado por diversos demonios que, lejos de limitarse a las funciones de init, está absorbiendo cada vez más funciones, procesos y demonios. Por ejemplo, el control de energía, manejo de puntos de montaje, encriptación de discos, configuración de red, etc. Miremos más atentamente el manejo de puntos de montaje. Éste proceso está controlado por udev que es el gestor de dispositivos del kernel Linux Su función es controlar los ficheros de dispositivo en /dev. Sin embargo, udev ha pasado a estar integrado en SystemD. Todos los programas que necesiten a udev como dependencia, ahora también dependen de Systemd.

Otro problema es el manejo de journal, un sistema de registro de incidencias que permite solucionar fácilmente fallos del sistema. SystemD ha modificado la forma en que trabaja respecto a opciones anteriores, haciéndola más compleja. Maneja journal mediante código binario fácilmente corruptible, además de otras problemáticas.

Todo esto tiene implicaciones preocupantes. Como el programa es cada vez más complejo, adquiere cada vez más código que puede fallar y colapsar al propio SystemD. Pero, recordemos, SystemD tiene PID 1. Si SystemD colapsa, también colapsa todo el sistema operativo. Peor aún es si SystemD colapsa debido a procesos que si fuesen independientes, no tendrían jamás PID 1 (y al colapsar no causaría daños tan graves). Por ejemplo, que por fallar udev colapse SystemD, y por tanto también el sistema entero.

De igual forma es cada vez más difícil o complejo poder revisar el programa para pulirlo y detectar deficiencias.

Pero, decíamos que SystemD tiene una perspectiva de “control unificado” por así decir, sobre el sistema (como acabamos de ver), abarcando cada vez más y más procesos. Pero por otro lado, también tiene una perspectiva unificadora sobre el ecosistema GNU/Linux: el objetivo es eliminar “diferencias sin sentido entre distribuciones”. Esto es repulsivo para muchas personas que precisamente, algo que aman del software libre en general y de GNU y Linux en particular, es que puede modificarse tanto como sea necesario. De hecho, no sólo diferentes pueden querer sistemas operativos que trabajen de diferentes maneras según los intereses de esas personas; incluso una misma persona puede querer usar diversos sistemas operativos que se ajusten a necesidades o gustos diversos.

 

 

SystemD, ¿sí o no?

La decisión de utilizar SystemD depende o bien de decisiones empresariales, como podría ser el caso de Ubuntu, o bien de decisiones tomadas por la comunidad correspondiente, como podría ser el caso de Arch. La decisión no es nada fácil, y SystemD no es la solución perfecta y definitiva. Pero es indudable que SystemD aporta beneficios indudables. Es por ello que tantas empresas y comunidades muy diferentes entre sí no lo habrían adoptado. A cambio, tiene también defectos muy serios, limitando la libertad del usuario y añadiendo numerosos puntos débiles que por sí mismos pueden colapsar el ordenador o incluso ser atacados por crackers y delincuentes. Lo deseable sería que cada quien pueda valorar si desea utilizar SystemD u otro init, y que la distribución que utilice le permita efectivamente usar alternativas a SystemD sin problema alguno… aunque esto parece cada vez más y más difícil. Aunque diversas distribuciones con SystemD por defecto tienen la opción de emplear sistemas de inicio alternativos a SystemD, estas alternativas son eso mismo: alternativas a “lo oficial” o a “lo predeterminado”. La información disponible es mucho menor, y no suele comentarse esas opciones antes de instalar la distribución; de tal forma que para muchos usuarios no existe alternativa a SystemD porque, para empezar, ni siquiera saben que su sistema operativo utiliza algo llamado Systemd. La falta de información es aquí el problema principal. Dada la naturaleza expansiva de SystemD, es probable que este proceso vaya en aumento, al convertirse o necesitarse cada vez más alternativas a procesos o programas absorvidos por SystemD.

Y hasta aquí va este pequeño resumen. A partir de los enlaces anteriores podéis ahondar en este tema. Cualquier defecto del artículo es culpa mía, y no de ellos. En particular es recomendable este artículo del blog linuxito, donde podéis comprobar más críticas a aspectos técnicos de SystemD. Espero que os haya interesado el artículo, y tal vez hayamos podido aprender algo juntos.

 

Nota: Derechos de autor de la imagen.

29
Deja una respuesta

avatar
21 Hilos de comentario
8 Respuestas de hilo
1 Seguidores
 
Comentario más reaccionado
El hilo de comentarios más caliente
17 Autores de comentarios
SergiohaevalenciaFranciscoeliotime3000amancio Autores de comentarios recientes
  Suscribirse  
Los más recientes Los más antiguos Más votados
Notificarme las
trackback
Usando systemd para gestionar servicios en Linux - webkode

[…] de systemd y usan su propio sistema de inicio ), Si queréis saber un poco más al respecto, en este blog lo explican con más […]

haevalencia
Invitado
haevalencia

Solo añadir dos cosas, si un servicio, socket o unidad falla, no falla todo systemd y el sistema como lo dices, simplemente se notifica el error y se puede reiniciar el servicio, socket o unidad fácilmente (es una de sus ventajas). Por otro lado el diseño de systemd no es nuevo y GNU fue la primera en plantear la idea de crear un administrador de sistema basado en daemos (DMD actualmente GNU Shepherd) y fue el primer reemplazo pensado para sysvinit.
Lo segundo lo mencioné indirectamente. El concepto es daemon y no “demonio”. Esa es una tradución/interpretación muy equivocada y si se busca más a fondo, en español lo más cercano sería “ángel de la guarda”.

haevalencia
Invitado
haevalencia

Solo añadir dos cosas, si un servicio, socket o unidad falla, no falla todo systemd y el sistema como lo dices, simplemente se notifica el error y se puede reiniciar el servicio, socket o unidad fácilmente (es una de sus ventajas). Por otro lado el diseño de systemd no es nuevo y GNU inició con la idea de crear un administrador de sistema basado en daemos (DMD actualmente GNU Shepherd) y fue el primer reemplazo pensado para sysvinit.
Lo segundo lo mencioné indirectamente. El concepto es daemon y no “demonio”. Esa es una tradución/interpretación muy equivocada y si se busca más a fondo en español lo más cercano sería “ángel de la guarda”.

Francisco
Invitado
Francisco

Gracias a systemd he dado el salto definitivo a OpenBSD. Este sistema es mucho más que una excelente alternativa y está 100% libre de esta aberración.

trackback
Usando systemd para gestionar servicios en Linux | systemctl

[…] de systemd y usan su propio sistema de inicio ), Si queréis saber un poco más al respecto, en este blog lo explican con más […]