- systemd 259 introduce soporte experimental para musl y refuerza su papel central en GNU/Linux, aunque con limitaciones importantes.
- La versión abandona TPM 1.2 en systemd-boot y systemd-stub, endurece requisitos mínimos y avanza hacia el fin de los scripts System V.
- Se amplían run0, systemd-oomd, journald, Varlink y los módulos de red, mejorando seguridad, telemetría y administración avanzada.
La llegada de systemd 259 supone otro giro de tuerca en el componente más influyente (y polémico) del ecosistema GNU/Linux moderno. Esta versión no solo incorpora cambios técnicos de calado, sino que también amplía el ámbito de actuación del proyecto, refuerza la seguridad y endurece los requisitos mínimos del sistema, afectando de forma directa a qué hardware y qué distribuciones podrán sacarle partido.
En esta entrega, el equipo de desarrollo introduce por primera vez soporte experimental para la libc musl, reorienta la seguridad hacia TPM 2.0, continúa puliendo su sustituto de sudo (run0), mejora la gestión de memoria con systemd-oomd y reestructura diversas piezas internas para reducir dependencias y optimizar su uso en contenedores. Todo ello sin frenar su conocida tendencia a integrar más y más funcionalidades bajo el paraguas de systemd.
systemd 259 y el papel central de systemd en GNU/Linux
Desde hace años, systemd se ha consolidado como el framework de sistema por defecto en la mayor parte de las distribuciones GNU/Linux de uso general. Actúa como PID 1, gestiona servicios, sesiones de usuario, el proceso de arranque, el registro de eventos, la red y un montón de piezas de bajo nivel que antes estaban repartidas entre múltiples herramientas y demonios independientes.
Este enfoque tan integrador y técnicamente ambicioso ha generado adhesiones y odios a partes iguales. Para algunos, simplifica la administración moderna de sistemas; para otros, concentra demasiado poder en un único proyecto y aumenta la complejidad. Sea como sea, cada nueva versión como systemd 259 introduce una lista enorme de cambios que afectan a los administradores, desarrolladores de distribuciones y usuarios avanzados.
Con systemd 259, el proyecto refuerza esa imagen de desarrollo muy activo y en constante expansión. Hay novedades en compatibilidad con bibliotecas C, cambios importantes en el arranque UEFI, mejoras en la IPC (Varlink), modificaciones en el manejo de la memoria, ajustes de seguridad y decisiones que impactan a la compatibilidad hacia atrás, como la futura eliminación de scripts System V.
Soporte experimental para musl: apertura más allá de glibc
Una de las novedades estrella de systemd 259 es la compatibilidad parcial con la biblioteca C musl, que se suma a la histórica dependencia del proyecto con glibc. Esto significa que, al menos de forma experimental, ahora es posible compilar y ejecutar systemd en distribuciones basadas en musl, como Alpine Linux, Void Linux, Adélie Linux o proyectos derivados.
El soporte se habilita ajustando la opción «libc» a «musl» en el sistema de compilación Meson. Sin embargo, los desarrolladores han dejado claro que no se trata de un soporte completo ni garantizado a largo plazo. Musl carece de ciertas funciones de NSS (Name Service Switch) que systemd utiliza intensivamente, lo que provoca recortes funcionales importantes.
Al compilar systemd contra musl quedan fuera componentes clave como nss-systemd, nss-resolve, systemd-homed, systemd-nsresourced, systemd-userdbd, el uso de DynamicUser y la posibilidad de ejecutar systemd-nspawn sin privilegios. Es decir, el corazón del gestor de servicios funciona, pero determinados módulos avanzados de gestión de usuarios, resolución de nombres y contenedores pierden soporte.
Este cambio no ha surgido de la nada: la motivación principal viene de proyectos como postmarketOS, que se basa en Alpine Linux y buscaba aprovechar systemd para mejorar la integración con GNOME y KDE Plasma orientados a dispositivos móviles. Su comunidad impulsó los parches necesarios para permitir la compilación con musl, y finalmente fueron aceptados por los mantenedores de systemd, aunque con bastante cautela.
Los desarrolladores han avisado de que no prometen mantener el soporte musl en futuras versiones. La continuidad dependerá de cómo evolucione una capa adicional que implemente las funciones que musl no proporciona, del interés real de los proyectos que usan esta libc y de la cantidad y calidad de los informes de errores específicos relacionados con musl. Dicho de otro modo, la puerta está abierta, pero no hay garantía de que vaya a permanecer así para siempre.
Más seguridad en el arranque: adiós a TPM 1.2 y mejoras en systemd-boot
Otro bloque importante de cambios en systemd 259 afecta al arranque UEFI, concretamente a los componentes systemd-boot y systemd-stub. A partir de esta versión se elimina la compatibilidad con TPM 1.2, manteniéndose únicamente el soporte para TPM 2.0, considerado más robusto y alineado con los requisitos de seguridad actuales.
Esto implica que quienes dependan de funciones de arranque seguro ligadas a TPM 1.2 se verán obligados a actualizar el hardware, normalmente cambiando la placa base o tirando de equipos más modernos que incluyan TPM 2.0. En el contexto doméstico, donde muchas personas optan por desactivar Secure Boot y TPM por comodidad o por problemas de compatibilidad, es probable que este cambio tenga un impacto limitado, pero en entornos corporativos y de alta seguridad sí puede ser un factor relevante.
Además de la cuestión del TPM, systemd-boot incorpora ahora la posibilidad de definir el nivel de log mediante el parámetro log-level en loader.conf o a través del campo SMBIOS io.systemd.boot.loglevel. Esto permite ajustar la verbosidad de los mensajes de arranque, algo útil tanto para depuración como para reducir ruido en entornos estables.
La documentación del proyecto también detalla que se endurecen los requisitos para la partición XBOOTLDR, que algunas distribuciones utilizan como partición adicional para almacenar el kernel y el initramfs cuando el ESP original se queda corto de espacio. Ahora se exige que esta partición use un sistema de archivos que pueda leer directamente el firmware UEFI (básicamente alguna variante de FAT), y no solo el kernel de Linux, lo que alinea su comportamiento con las limitaciones reales del hardware.
Conviene recordar que systemd-boot solo funciona en sistemas UEFI y que no está tan extendido como GRUB, aunque distros como Pop!_OS han apostado por él en el pasado. Su aproximación, basada en colocar el kernel y el initramfs directamente en la partición EFI, tiene ventajas y riesgos, especialmente cuando es necesario redimensionar esa partición, algo que ya ha provocado más de un susto en equipos de pruebas.
run0 y el nuevo enfoque para elevar privilegios
En versiones recientes, el proyecto ha ido impulsando run0 como alternativa moderna a sudo, construida sobre systemd-run. La idea es ofrecer una herramienta que permita ejecutar comandos con privilegios elevados de forma más controlada, integrada con el ecosistema systemd y con un modelo de seguridad más granular basado en capacidades.
Con systemd 259 se introduce la nueva opción «run0 –empower», que permite iniciar una sesión con privilegios elevados sin cambiar explícitamente al usuario root ni modificar el UID. En su lugar, se ajustan ciertas capacidades del proceso, como CAP_SYS_ADMIN y otras que habilitan la mayoría de llamadas al sistema privilegiadas necesarias.
Los procesos que se inician con –empower se asignan a un grupo especial «empower», que tiene acceso a un amplio conjunto de acciones Polkit, lo que facilita autorizar operaciones administrativas de manera más flexible que con el clásico modelo de «todo o nada» asociado a root. El objetivo general es reducir al mínimo el uso directo de la cuenta root, algo que se considera buena práctica de seguridad en prácticamente cualquier entorno.
Además de –empower, systemd-run y run0 reciben la opción «–same-root-dir» (-R), que permite lanzar servicios usando el mismo directorio raíz del proceso que los ejecuta. Esto viene acompañado de la opción «–root-directory» en systemd-run, pensada para iniciar un servicio en un directorio raíz alternativo, útil en tareas de mantenimiento, chroot avanzados o escenarios de recuperación.
Aunque aún es pronto para saber hasta qué punto run0 desplazará a sudo en el día a día, está claro que el equipo de systemd está apostando fuerte por integrarlo como pieza central para la elevación de privilegios en entornos gestionados por systemd, con una filosofía más alineada con contenedores, cgroups y capacidades.
Gestión de memoria y OOM: nuevas métricas en systemd-oomd
La gestión de situaciones de memoria insuficiente también recibe atención en systemd 259 gracias a mejoras en systemd-oomd, el componente encargado de reaccionar cuando algún proceso se come la RAM y amenaza con tumbar el sistema. Este módulo había recibido críticas en el pasado por ser demasiado agresivo, así que ahora se apuesta por mayor visibilidad y capacidad de diagnóstico.
Se añaden las propiedades OOMKills y ManagedOOMKills para los servicios gestionados por systemd. Estas propiedades contabilizan, respectivamente, el número de procesos terminados a la fuerza por el kernel (OOM killer tradicional) y por el propio systemd-oomd. De esta forma, los administradores pueden analizar qué unidades están provocando más problemas de memoria y cómo está actuando el sistema para impedir el colapso.
Esta información de seguimiento es especialmente útil en entornos con cargas de trabajo muy variables, como contenedores, servicios web con picos de tráfico o entornos de escritorio donde ciertas aplicaciones pueden descontrolarse y consumir exceso de RAM. Disponer de métricas claras facilita tanto la depuración como el ajuste fino de límites de memoria por servicio.
Los cambios en systemd-oomd se complementan con ajustes en otras áreas de gestión de dispositivos y particiones, como la capacidad de systemd-udevd y systemd-repart para volver a leer tablas de particiones de forma más gradual e incremental, reduciendo el impacto de estos cambios en sistemas en producción.
Endurecimiento de requisitos y fin progresivo de System V scripts
En la parte de compatibilidad hacia atrás, systemd 259 marca una línea más clara respecto a tecnologías heredadas. El proyecto anuncia la eliminación del soporte para scripts de arranque al estilo System V en la próxima versión (systemd 260). Esto implica la retirada de componentes como systemd-sysv-install, systemd-rc-local-generator y systemd-sysv-generator.
De facto, muchas distribuciones llevaban tiempo migradas a unidades nativas de systemd, pero todavía quedaban restos de compatibilidad para scripts clásicos. La retirada definitiva empuja a quien aún dependa de esos mecanismos a migrar por completo, algo especialmente relevante en sistemas antiguos, instalaciones muy personalizadas o entornos donde sobreviven scripts heredados.
En paralelo, se actualizan los requisitos mínimos de versiones para varios componentes base. Para ejecutar systemd 259 hacen falta, como mínimo:
- Linux 5.10 como versión de kernel mínima (siendo 5.14 la recomendada).
- glibc 2.34 cuando se usa la libc de GNU.
- OpenSSL 3.0.0 y Python 3.9.0.
- Bibliotecas como libxcrypt 4.4.0, util-linux 2.37, elfutils 0.177, cryptsetup 2.4.0 y libseccomp 2.4.0.
Estos requisitos reflejan una apuesta clara por plataformas relativamente recientes, lo que mejora la coherencia y la seguridad del conjunto, pero deja fuera hardware muy antiguo o distribuciones que insisten en mantener stacks extremadamente conservadores.
Reducción de dependencias y carga dinámica en libsystemd
En el terreno interno, libsystemd introduce un cambio relevante en cómo gestiona sus dependencias. A partir de esta versión, varias bibliotecas habituales dejan de enlazarse de manera estática en tiempo de compilación y pasan a cargarse dinámicamente mediante dlopen() solo cuando sus funciones son realmente necesarias.
Entre las bibliotecas afectadas destacan libacl, libblkid, libseccomp, libselinux y libmount, además de la integración con el subsistema de auditoría de Linux y con PAM. Esto permite reducir el tamaño y la huella de systemd en entornos como contenedores, donde no siempre se necesitan todas esas capacidades adicionales.
Otra novedad es que la funcionalidad que antes se exponía a través de la capa libcap se integra ahora directamente dentro de libsystemd, simplificando el árbol de dependencias y concentrando más lógica en una única biblioteca central.
Este enfoque orientado a cargar solo lo justo y necesario en tiempo de ejecución tiene ventajas obvias en términos de footprint y flexibilidad, aunque también implica mayor complejidad a la hora de depurar problemas ligados a dependencias ausentes o versiones incompatibles en tiempo de ejecución.
Mejoras en red, resolución de nombres y Varlink
systemd 259 también dedica esfuerzos notables a mejorar la capa de red y la comunicación entre procesos. Una de las áreas más activas es la ampliación de la API basada en Varlink, que permite acceder a la configuración de servicios y a diversas funcionalidades del ecosistema systemd a través de un protocolo IPC moderno.
Se implementan nuevas llamadas como Reload() y Reexecute() en la interfaz IPC del gestor de servicios, además de métodos específicos para gestionar y consultar funcionalidades de systemd-repart, systemd-resolved y systemd-networkd. Esto facilita la creación de herramientas de administración que interactúen de forma más limpia y estructurada con systemd.
En el ámbito de la resolución de nombres, systemd-resolved permite ahora conectar “hooks” locales que se ejecutan cada vez que se realiza una consulta DNS local. Estos ganchos se almacenan en el directorio /run/systemd/resolve.hook/ y permiten, por ejemplo, registrar trazas personalizadas, activar lógicas de auditoría o disparar acciones cuando se resuelven ciertos dominios.
Por el lado de la red, systemd-networkd y systemd-nspawn dejan de soportar la creación de reglas de NAT basadas en iptables/libiptc. A partir de ahora solo se mantiene soporte para nftables, reforzando el movimiento general del ecosistema Linux hacia el nuevo framework de filtrado y traducción de paquetes del kernel.
Asimismo, se añaden las opciones EmitDomain y Domain en systemd-networkd para el servidor DHCP, y se implementa un controlador que determina los nombres de host entregados por DHCP mediante resolución DNS. Todo ello encaja con la vocación de systemd de gestionar cada vez más aspectos de la pila de red desde un punto central.
Cambios en journald, importación de sistemas e imágenes de máquinas
En el frente del registro de eventos, systemd-journald cambia su modo de almacenamiento por defecto. Hasta ahora, el modo “auto” decidía si los logs se guardaban en memoria volátil o de forma persistente según la presencia de /var/log/journal. Con systemd 259, el modo predeterminado pasa a ser «persistente», por lo que se asume que los registros deben guardarse en disco salvo configuración en contra.
Este ajuste favorece una mayor trazabilidad de problemas y auditoría, a costa de un consumo de disco algo superior. Los administradores que no quieran logs persistentes deberán desactivar explícitamente esa opción o ajustar la configuración a sus necesidades.
En cuanto a la gestión de imágenes de sistemas, systemd-importd incorpora lógica integrada para trabajar con archivos TAR, reutilizando la funcionalidad de libarchive de la utilidad tar de GNU. Además, tanto systemd-machined como systemd-importd pueden ejecutarse ahora en modo por usuario, y no solo a nivel de sistema, utilizando imágenes almacenadas en ~/.local/state/machines/.
Para controlar estos modos se añaden las opciones «–user» y «–system» a la utilidad importctl, permitiendo que usuarios sin privilegios gestionen imágenes propias de forma aislada cuando así se permita. También se introduce un comportamiento por defecto en systemd-machined que obliga a montar en modo solo lectura las imágenes de disco «ocultas» (aquellas cuyo nombre comienza por un punto), aumentando la protección frente a modificaciones accidentales.
Por otra parte, systemd-sysext y systemd-confext cuentan ya con archivos de configuración dedicados (/etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.conf, respectivamente). Se añaden además las variables de entorno SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS para ajustar las opciones de montaje de Overlayfs, dando más control sobre cómo se activan extensiones de sistema y de configuración.
Udev, homed y otras mejoras específicas
El ecosistema de udev y homed también recibe varias pequeñas mejoras que, aunque menos vistosas, resultan muy útiles en escenarios concretos. Por ejemplo, systemd-udevd añade la opción OPTIONS=»dump-json» para mostrar el estado actual de un evento en formato JSON, lo que facilita muchísimo la depuración de reglas udev complejas.
La función net_id genera ahora nombres predecibles para interfaces inalámbricas en sistemas que utilizan DeviceTree, alineando la nomenclatura de tarjetas de red wifi con la de las interfaces Ethernet. Además, se crean enlaces simbólicos /dev/gpio/by-id/… para dispositivos GPIO, simplificando la identificación coherente de estos recursos en sistemas integrados.
En el ámbito de usuarios domésticos gestionados por systemd-homed, se añaden nuevas capacidades: el comando «homectl update» soporta la opción «–recovery-key» para añadir claves de recuperación a cuentas ya existentes (antes solo se podían configurar al crear el usuario). También aparecen las opciones «–prompt-shell» y «–prompt-groups» en systemd-homed, que permiten seleccionar interactivamente shell y grupo durante el primer arranque mediante systemd-homed-firstboot.service.
Para mejorar la experiencia inicial de instalación, systemd-firstboot suma la opción «–prompt-keymap-auto», que solicita automáticamente la distribución de teclado al usar la consola local durante el primer arranque. Estos detalles facilitan despliegues desatendidos o semiautomatizados sin renunciar a cierto grado de personalización.
En el campo de la integridad, systemd-integrity-setup añade soporte para algoritmos HMAC-SHA256, PHMAC-SHA256 y PHMAC-SHA512, ampliando el abanico de opciones criptográficas disponibles para verificar la integridad del sistema y reforzar la seguridad en entornos que exigen controles más estrictos.
Novedades en unidades, namespaces y carga de módulos
La definición y ejecución de unidades de servicio también suman detalles interesantes. Se introduce la configuración ExecReloadPost, que permite ejecutar comandos después de recargar la configuración de un servicio. Esto abre la puerta a escenarios donde sea necesario lanzar acciones complementarias tras un reload sin tener que encajarlas a la fuerza en ExecReload.
Para servicios temporales se incorpora la propiedad RootDirectoryFileDescriptor, que define el descriptor de archivo asociado al directorio raíz, encajando con usos avanzados de chroot y espacios aislados. Además, se añade la opción «UserNamespacePath», que permite vincular una unidad a un namespace de usuario especificando la ruta correspondiente en /proc, en la misma línea de las ya existentes «IPCNamespacePath» y «NetworkNamespacePath».
En systemd-nspawn, esta idea se extiende con la opción «NamespacePath» dentro de la sección [Network] de los archivos .nspawn, que sirve para indicar explícitamente qué espacio de nombres de red utilizar. Esto resulta especialmente útil en despliegues con múltiples contenedores y topologías de red complejas.
Por último, systemd-modules-load implementa carga paralela de módulos del kernel, acelerando el proceso de inicialización en sistemas con gran cantidad de módulos a cargar. Aunque el impacto exacto depende de cada entorno, en general se puede esperar un arranque algo más rápido en equipos con hardware variado o muchas funcionalidades del kernel habilitadas como módulos.
Como toque adicional, los archivos de configuración que terminen en «.ignore» pasan a ser ignorados automáticamente. Esto da un mecanismo sencillo para desactivar configuraciones sin tener que borrarlas o moverlas a otro sitio, muy práctico a la hora de hacer pruebas o de gestionar paquetes que instalan configuraciones por defecto que el administrador quiere deshabilitar temporalmente.
systemd 259 consolida aún más su posición como pieza central del ecosistema Linux. Abre la puerta a distribuciones basadas en musl, endurece la seguridad del arranque con el giro definitivo hacia TPM 2.0, refuerza la telemetría sobre situaciones de memoria crítica, racionaliza dependencias internas vía dlopen, amplía la API Varlink y afina detalles en red, journald, homed, udev y gestión de imágenes. Aunque muchas distribuciones de ciclo fijo congelarán una versión concreta de systemd durante toda su vida útil, quienes apuestan por lanzamientos continuos como Arch Linux u openSUSE Tumbleweed empezarán a notar estos cambios antes, mientras el eterno debate sobre la centralización y complejidad de systemd sigue vivo en la comunidad.