Impresiones de uso sobre SystemD

Hace unos meses ya, hice el cambio de Debian (rama "testing") a Arch Linux. Uno de las distintas cosas a las que tuve que adaptarme en esa migración fue pasar de un sistema que por ese entonces aún utilizaba SysVinit como gestor de servicios a uno que utiliza SystemD. Para mí este era un punto importante, debido a las conocidas quejas que ha habido (y sigue habiendo) sobre SystemD. Hoy he querido compartir con vosotros mis impresiones sobre este sistema.

La experiencia de usuario de un gestor de servicios no es algo que se constate de la misma forma que, por ejemplo, la de un entorno de escritorio o una aplicación en concreto. El gestor de servicios es un elemento que, bajo funcionamiento normal, no se interpone en el funcionamiento del sistema: una vez que el sistema arranca el núcleo y este le pasa el relevo al proceso init, si no hay problemas (y no debería haberlos si todo está configurado como debe), se iniciará la entrada de usuario (ya sea login en una consola o el gestor gráfico) y, a partir de allí, las veces que será necesaria una interacción del usuario con el gestor de servicios serán muy contadas (básicamente, cuando se tiene que configurar un nuevo servicio y esto solo si el gestor de paquetes no lo hace ya por sí mismo). Así que no estamos hablando aquí de un componente que el usuario utilice constantemente, aunque el sistema sí.

Hay un par de cosas que se suelen de decir de SystemD que un usuario curioso notará enseguida cuando uno viene de SysVinit es que SystemD toma el control de una serie de elementos que su antecesor no, pero el que posiblemente más salte a la vista en un principio sea el hecho de que SystemD controle el registro del sistema. Para revisar el registro en un sistema que opera con SystemD, tendremos que conocer una herramienta nueva, journalctl, debido a que los registros se guardan en un formato binario, por lo que tenemos que abandonar el hábito de hacer pasar los registros por el paginador (less, generalmente) y usar grep para buscar la línea que nos interese.

Otra de las grandes diferencias está, evidentemente, en la gestión de los servicios. Este es un aspecto que será más o menos visible dependiendo de dos factores, según mi punto de vista: si la distribución que usamos gestiona la configuración de servicios de forma automatizada (mediante scripts de instalación ejecutados por el gestor de paquetes) y si somos usuarios que toqueteamos más o menos el sistema (si no lo hacemos y nos contentamos con lo que nos viene preconfigurado, ni nos interesará qué gestor de servicios tengamos). En mi caso estamos hablando de Arch Linux, una distribución que no configura automáticamente ningún servicio instalado por paquetes, por lo cual el usuario está obligado a tomar una decisión sobre si quiere ejecutar el servicio, cosa que me ha expuesto a SystemD bastante más que utilizando Fedora, por ejemplo.

Un aspecto interesante de SystemD es los cuatro estados que puede tener un servicio: habilitado/deshabilitado y iniciado/detenido. SysVinit solo compartía con SystemD la última pareja: un servicio estaba en ejecución o no y uno podía detenerlo y reiniciarlo a través de la línea de comandos (existía service o, simplemente, se podía invocar el script del servicio con los argumentos que uno quería). Si bien Fedora soportaba nativamente una interfaz algo más abstracta que simulaba la habilitación y deshabilitación de servicios (chkconfig) y Debian tiene update-rc.d(aunque tenga los días contados), la verdad es que SysVinit no conocía estos conceptos; es decir, SysVinit siempre ejecutaría todos los servicios que se encontraran bajo /etc/rc*.d y, por tanto, la única forma de evitar ejecutar un servicio era borrar el symlink que apuntaba al script alojado en /etc/init.d. SystemD, en cambio, implementa la idea de poder desactivar un servicio de forma nativa con una simple invocación a systemctl, sin implicar en la práctica una desinstalación del servicio (es que borrar el symlink lo que conllevaba era, justamente, una desinstalación por medio de cortar el acceso al script).

No soy de los que escriban servicios, así que no puedo opinar realmente sobre cuán cómodo es el nuevo formato que utiliza SystemD para definirlos (es un formato que recuerda bastante a los archivos INI de Windows; daros una vuelta por /usr/lib/systemd/system y /usr/lib/systemd/user). Lo que sí es evidente es que, habiendo dejado de lado el rudimentario sistema anterior basado enteramente en scripts de shell, se gana algo de seguridad y de eficiencia. El hecho de no tener que estar ejecutando scripts con privilegios de administrador es un riesgo: un script puede contener código arbitrario y todo lo que hacía SysVinit era, simplemente, ejecutarlos sin controlarlos. Por otro lado, es evidente que los servicios no pueden iniciarse en un orden aleatorio: por ejemplo, KDM siempre requerirá que el servidor X esté en marcha antes. SysVinit se las arreglaba con un complejo sistema de directorios y convenciones de nombres de archivo para determinar qué se tenía que ejecutar cuándo, cosa que solo pueden determinar los desarrolladores en el nivel de la distribución para evitar nombres duplicados o inconsistencias. En cambio, estos nuevos archivos de "unidades" (units, que pueden servicios u "objetivos", targets) de SystemD permiten especificar las dependencias del servicio en el propio archivo, por lo que se simplifica enormemente la jerarquía de directorios y, además, se evita la ejecución de código arbitrario directamente desde init. Obviamente el ejecutable al que se hace referencia en el archivo del servicio puede ser dañino (intencionadamente o no), pero el problema queda, entonces, aislado solo en el ejecutable que implementa el servicio; en cambio, con el sistema anterior, el problema debía buscarse en dos ejecutables (el script y el servicio en sí mismo).

Una de las críticas más extendidas contra SystemD es que viola la filosofía UNIX de "una sola herramienta, una sola funcionalidad (y hacerla bien)". Por ejemplo, una de las quejas concretas más extendidas es que SystemD controla los cronjobs en /etc/cron* que antiguamente controlaba(ana)cron independientemente del init utilizado. Aquí creo que hay que poner un poco de perspectiva, porque no es lo mismo SystemD que la interfaz a la que se accede para manipular su funcionamiento, es decir, el uso de systemctl y archivos de "unidades". En realidad, SystemD no es muy distinto a SysVinit, salvo por el hecho de que, en su momento, había cosas que, aún pudiendo hacerse, había ciertas cosas que los desarrolladores preferían mantener como separadas del gestor de servicios porque no consideraban que fueran parte del procedimiento de arranque del sistema. El problema es que las distribuciones fueron convergiendo, por ejemplo, en iniciar (ana)cron como un servicio, de manera que hoy se consideran parte del proceso de arrancar un sistema Linux más o menos "estándar". Y como son parte del proceso de arranque, los desarrolladores han querido implementar estos componentes como parte de SystemD, aunque en realidad están implementados como servicios que SystemD, simplemente, arranca cuando haga falta. Da igual que un servicio se configure para ejecutarse cada 24 horas, si para ello hace falta encender el contador al arrancar el sistema, entonces es un servicio que, aunque latente, requiere ser iniciado por init. Es por ello que el truco antiguo con SysVinit de delegar en (ana)cron la ejecución de los cronjobs no era más que una ilusión de abstracción.

Finalmente, creo que es imposible hablar de SystemD sin hablar de cgroups, la interfaz del núcleo Linux que permite controlar y gestionar una serie de propiedades de los procesos para evitar, por ejemplo, la colisión de números PID y restringir cuántos recursos pueden utilizar cada uno. El problema es que cgroups es una característica exclusiva del núcleo Linux que SystemD utiliza para brindar mayor seguridad y eficiencia, por lo que SystemD no podrá utilizarse jamás en BSD o GNU Hurd (salvo que se implemente cgroups en esos núcleos). Esta es una de las razones que llevó a Debian a dudar tanto tiempo en si convenía migrar o no de sistema de init. La cuestión es que, en parte, era inevitable que esto sucediera: los SysVinit utilizados en distribuciones Linux ya no eran totalmente compatibles con BSD y SystemD, en parte, intenta recoger usos y formas que se han ido "acumulando" en el arranque de un sistema Linux convencional. Es un proyecto creado para Linux: no podemos culparlo por ello y menos cuando la razón es para usar una muy buena característica propia de este núcleo en particular. Aun cuando la interoperabilidad siempre es bienvenida, dejar de aprovechar en un proyecto tan vital las ventajas de la plataforma subyacente solo para garantizar un uso potencial de una plataforma totalmente diferente no tiene mucho sentido.

En mi opinión y experiencia de uso, SystemD es un buen avance. Por supuesto, no se le puede negar la razón a Linus Torvalds cuando acusó a los desarrolladores de SystemD de invasivos por querer introducir modificaciones en el núcleo solo en beneficio de su proyecto. Es cierto que Lennart Poettering es un personaje complicado, muy vinculado a Red Hat, que ya protagonizó un momento polémico de la historia de Linux cuando creó Pulseaudio como reemplazo de ALSA. Es un personaje con muy buena visión de futuro, que crea muy buenos proyectos, pero muy arrogante en las formas de convencer a la gente de que su solución es interesante (él la considera la mejor posible, con la exclusión que eso conlleva). Sin embargo, como ya ocurrió con Pulseaudio, creo que SystemD está aquí para quedarse. Y los problemas que pueda tener, comparado con SysVinit, hay que ponerlos en el contexto de que SystemD es un gestor de servicios que no tiene más de 4 años y que en ese tiempo ha reemplazado en una buena cantidad de distribuciones a un veterano heredado de los sistemas UNIX de los años 80.