- Systemd 260 elimina definitivamente el soporte a scripts System V y exige unidades nativas para todos los servicios.
- La versión refuerza la integración con TPM2, incluyendo gestión de la SRK y utilidades como tpm2_id y systemd-pcrextend.
- Se amplían de forma notable las capacidades de sandboxing, control de red y recursos por servicio, junto con nuevas opciones para contenedores y máquinas efímeras.
- El proyecto incorpora documentación específica para agentes de IA y nuevos flujos de revisión asistida para mejorar la calidad de las contribuciones.
Con la llegada de systemd 260 las distribuciones Linux dan otro paso importante hacia un ecosistema más moderno, seguro y orientado a entornos cloud, virtualización y automatización. Esta versión no se limita a pulir detalles: introduce cambios de calado en el arranque, en el manejo de servicios, en la red, en el uso de TPM2 para integridad y cifrado, y en las capacidades de aislamiento (sandboxing) a nivel de unidad.
Al mismo tiempo, el proyecto refuerza su documentación y su forma de trabajar con agentes de inteligencia artificial, dejando claro que systemd es un pilar crítico al que cada vez se conectan más herramientas de desarrollo y observabilidad. Si administras sistemas Linux en servidores, cloud, escritorios corporativos o laboratorios, merece la pena revisar con calma todas estas novedades para planificar actualizaciones y ajustes de configuración.
Adiós definitivo a System V y dependencia total de unidades nativas
Uno de los cambios más llamativos de systemd 260 es la retirada completa del soporte para scripts de System V. El arranque clásico basado en /etc/init.d llevaba años en fase de retirada, pero ahora desaparece de forma efectiva del código de systemd.
Esto se traduce en que los componentes responsables de puentear entre scripts SysV y unidades nativas se han eliminado: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator y systemd-sysv-install dejan de existir. Como consecuencia, cualquier servicio que aún dependiera de estos mecanismos heredados simplemente no arrancará en sistemas que adopten systemd 260.
En el proceso de limpieza también se han marcado como obsoletas o se han retirado varias opciones de compilación de Meson. Las banderas -Drc-local=, -Dsysvinit-path= y -Dsysvrcnd-path= pasan al baúl de los recuerdos, mientras que otras como -Dintegration-tests= y -Dcryptolib= se eliminan directamente. Es un mensaje claro: todo debe pasar por unidades nativas y por la infraestructura moderna de systemd.
Para muchas infraestructuras europeas que aún conservan piezas antiguas, este cambio obliga a revisar servicios internos, scripts caseros y despliegues heredados. Migrar a unit files bien definidos ya no es recomendable: es obligatorio si se quiere seguir arrancando servicios en distribuciones que integren systemd 260.
Requisitos de kernel más altos y foco en entornos actuales
La nueva versión sube el listón del kernel: a partir de ahora, la versión mínima de Linux soportada es la 5.10, dejando atrás ramas muy veteranas como la 5.4. Además, el proyecto señala que lo ideal es trabajar sobre un kernel 5.14 o superior, y recomienda especialmente la serie 6.6 para aprovechar todas las funcionalidades disponibles.
Este aumento en los requisitos no suele ser un problema en distribuciones modernas, pero puede complicar la vida en entornos muy conservadores o en soluciones empotradas mantenidas durante muchos años. Antes de actualizar a systemd 260 conviene verificar qué kernel se está usando, especialmente en centros de datos europeos con despliegues de larga duración o en imágenes personalizadas.
En el extremo opuesto, las distribuciones de lanzamiento continuo como Arch Linux o openSUSE Tumbleweed, muy populares entre quienes quieren lo último, suelen incorporar con rapidez tanto nuevos kernels como nuevas ramas de systemd. Otras como Fedora mantienen cierta estabilidad en la versión mayor de systemd durante el ciclo de vida de cada release, lo que da algo más de margen para planificar migraciones.
TPM2, integridad del arranque y soporte avanzado de SRK
Uno de los frentes donde más está evolucionando systemd es en la integración con TPM2 (Trusted Platform Module 2.0). Este chip, cada vez más habitual en placas UEFI modernas y en hardware de gama media y alta, permite anclar secretos al estado del sistema, medir fases de arranque y desbloquear volúmenes cifrados de forma automática cuando el entorno es el esperado.
Systemd 260 profundiza en esta integración añadiendo herramientas y servicios que cubren distintos momentos del boot. Una pieza clave es systemd-tpm2-setup, responsable de preparar la infraestructura en torno a la Storage Root Key (SRK) del TPM. Esta clave raíz sirve como fundamento criptográfico para asegurar la comunicación con el chip y para almacenar de forma protegida otros secretos.
Durante el arranque se distinguen dos fases: una muy temprana en el initrd y otra ya en el sistema raíz. En la primera, un servicio de “Early TPM SRK Setup” comprueba si el TPM ya tiene una SRK almacenada y, en caso de que no exista, la crea y la deja disponible de forma temporal bajo /run/systemd/tpm2-srk-public-key.*. Más adelante, una vez montado el sistema de archivos real, el servicio consolidará la SRK y verificará que la clave almacenada en /var/lib/systemd/tpm2-srk-public-key.pem coincide con la que hay en el TPM.
En escenarios bien configurados se ven entradas en el journal del estilo «SRK ya está almacenada en el TPM» y mensajes que indican que la huella de la SRK corresponde con la esperada. Si, por el contrario, el entorno no está alineado (por ejemplo, en montajes con Yocto o en placas como Raspberry Pi con TPM por SPI y arranques personalizados con U‑Boot y measured boot), pueden darse situaciones en las que systemd no llegue a crear esos ficheros bajo /var/lib/systemd, generando dudas sobre si la SRK se ha configurado correctamente.
Cuando el estado del TPM ha cambiado, se han tocado particiones o se ha modificado el flujo de arranque, es posible que la política asociada ya no encaje. En esos casos algunos mantenedores recomiendan limpiar el slot o la política TPM y volver a matricular la clave, siguiendo procedimientos similares a los descritos en guías de cifrado de disco con TPM en entornos como openSUSE, donde se detalla cómo recrear la política de PCR y re-enlazar el desbloqueo de volúmenes.
Al margen de la SRK, otra mejora práctica es la introducción en udev de una utilidad interna llamada tpm2_id. Esta herramienta integrada se ejecuta cuando el sistema detecta un dispositivo TPM2 y extrae de forma automática el identificador de fabricante y el modelo. Con ello se simplifica el inventario de hardware de seguridad, algo muy útil en administraciones públicas, empresas reguladas o infraestructuras críticas donde hay que saber con precisión qué módulos TPM están desplegados.
La integración con la infraestructura de medición de arranque también se refuerza con unidades específicas como systemd-pcrextend, que registran en distintos PCR (por ejemplo el PCR 11) eventos como “enter-initrd”, “leave-initrd”, “sysinit” o “ready”. Esa secuencia de extensiones hace que el TPM acumule un registro criptográficamente verificable del flujo de arranque, que puede utilizarse después para políticas de Trusted Boot o para UKI (Unified Kernel Images) que validen el estado de la máquina antes de liberar claves.
Medidas de seguridad y sandboxing de servicios con systemd
Systemd no sólo arranca procesos: también ofrece un conjunto muy amplio de directivas de sandboxing para aislar servicios y limitar el daño en caso de compromiso. Este enfoque de “defensa en profundidad” se apoya en cgroups, namespaces, capabilities del kernel y filtros de llamadas al sistema (seccomp).
Para evaluar la situación de un servicio concreto, systemd incluye la herramienta systemd-analyze security. Al ejecutarla, genera un informe con un índice de exposición en una escala de 0 a 10, donde cuanto más bajo, mejor. El informe desglosa protecciones activadas o ausentes (aislamiento de red, acceso al sistema de archivos, dispositivos, etc.), de modo que resulta muy sencillo detectar qué ajustes faltan y comprobar si los cambios introducidos mejoran realmente la puntuación.
En lugar de editar la unidad original —lo que se perdería en futuras actualizaciones de paquetes— lo recomendable es crear un override en /etc/systemd/system/mi-servicio.service.d/ con un archivo, por ejemplo, sandbox.conf. Tras modificarlo, basta con recargar la configuración con systemctl daemon-reload y reiniciar el servicio para que las nuevas restricciones entren en vigor.
En el plano del sistema de archivos, una de las opciones más importantes es ProtectSystem=. Valores como strict, full o true montan distintas partes del árbol en modo sólo lectura. Lo habitual, cuando es posible, es usar ProtectSystem=strict, que hace que /usr, /boot, /efi y /etc sean de solo lectura para el servicio. Si una aplicación necesita escribir en directorios concretos se le permite mediante ReadWritePaths=/ruta en la unidad.
Para reforzar la privacidad se recomienda también Vetar el acceso a los directorios de usuario mediante ProtectHome=true, que impide que el servicio pueda leer /home, /root o /run/user. Además, PrivateTmp=true crea un espacio /tmp y /var/tmp aislado, evitando la visibilidad cruzada de ficheros temporales entre procesos.
En dispositivos, PrivateDevices=true oculta el árbol /dev real y lo sustituye por un conjunto mínimo de pseudo-dispositivos seguros (null, zero, random, etc.). Si una unidad necesita un dispositivo concreto (por ejemplo, un puerto serie o un bloque de disco), se puede conceder mediante DeviceAllow=/dev/xxx rw o en modo sólo lectura.
La red también es un vector clave. Con PrivateNetwork=true se crea un namespace de red aislado, dejando únicamente el loopback; el servicio no verá interfaces físicas ni podrá comunicarse con el exterior. Alternativamente, se puede restringir qué familias de direcciones puede usar mediante RestrictAddressFamilies=, permitiendo sólo AF_INET y AF_INET6 para IPv4/IPv6, AF_UNIX para sockets locales o incluso none para japonizar por completo las capacidades de red.
En cuanto a privilegios, la directiva NoNewPrivileges=true es de las más poderosas: impide que el proceso adquiera nuevos privilegios mediante binarios setuid o cambios de capabilities. En suma, aunque el servicio ejecute código vulnerable, no debería poder escalar a root a través de los mecanismos clásicos. Combinado con CapabilityBoundingSet=, que define la lista exacta de capacidades permitidas (por ejemplo, sólo CAP_NET_BIND_SERVICE para escuchar en puertos bajos), se reduce al mínimo la superficie de ataque.
Para ir todavía más lejos, systemd permite filtrar llamadas al sistema con SystemCallFilter=. En lugar de mantener una lista manual de syscalls, se usan grupos predefinidos como @system-service, @network-io, @basic-io o negar grupos como ~@privileged. Con systemd-analyze syscall-filter es posible inspeccionar qué llamadas concretas forman parte de cada grupo. De esta forma, se construye un perfil de ejecución muy limitado, similar a lo que ofrecería un sandbox dedicado.
Otros ajustes relevantes son ProtectKernelTunables=true, que bloquea la modificación de parámetros del kernel en /proc/sys y /sys, ProtectKernelModules=true, que evita cargar o descargar módulos, ProtectKernelLogs=true, que impide leer los registros del kernel, y ProtectControlGroups=true, que bloquea escrituras en la jerarquía de cgroups. Todo ello combina a la perfección con nuevas capacidades de aislamiento de usuario como PrivateUsers=full, que en la versión 260 se actualiza para mapear el rango completo de IDs de usuario, eliminando trucos anteriores necesarios para entornos con systemd anidado.
PrivateUsers, xaccess y nuevos controles de acceso a dispositivos
El mecanismo PrivateUsers, pensado para que los servicios se ejecuten en un espacio de IDs de usuario aislado, se consolida en systemd 260. La opción PrivateUsers=full ahora mapea el rango completo de identificadores, lo que simplifica la vida en contenedores y en sistemas con instancias de systemd anidadas que se basan en versiones algo antiguas (anteriores a la 257). Esta mejora ha permitido eliminar hacks que se utilizaban para detectar esas instancias antiguas.
En paralelo, componentes como systemd-logind y systemd-udevd estrenan el concepto de xaccess. Este mecanismo complementa la lógica clásica de uaccess, que concede acceso a ciertos dispositivos (por ejemplo, de audio o vídeo) a usuarios con sesiones gráficas en primer plano en la máquina local. Con xaccess se pueden delegar permisos a usuarios remotos con sesiones marcadas de forma especial, de forma que, por ejemplo, un usuario conectado por escritorio remoto pueda acceder a dispositivos de renderizado GPU locales sin otorgar permisos amplios a todo el sistema.
La configuración de estas sesiones pasa por variables de entorno expuestas vía PAM, en concreto PAMXDG_SESSION_EXTRA_DEVICE_ACCESS=, que permite definir qué dispositivos concretos entran en esta lógica. Es un enfoque muy alineado con las necesidades de cumplimiento normativo y protección de datos en la Unión Europea, donde se exige granularidad y trazabilidad en el acceso a hardware sensible.
mstack, systemd-mstack y nuevas herramientas para contenedores
En el ámbito de la contenerización, systemd 260 introduce la funcionalidad mstack y un comando asociado, systemd-mstack. La idea detrás de mstack es permitir definir un OverlayFS a partir de la estructura de un directorio especial llamado .mstack/, que sigue una especificación concreta para organizar sus capas.
El nuevo comando de línea, systemd-mstack, facilita trabajar con estas “pilas” de sistemas de ficheros de forma interactiva, añadiendo flexibilidad a la hora de montar entornos superpuestos para contenedores o servicios muy aislados. Esta funcionalidad está ligada también a mejoras en systemd-importd, que amplía su soporte para descargar y gestionar imágenes OCI, reforzando así el papel de systemd como motor de containerización y sandboxing, algo muy habitual en proveedores de cloud europeos y plataformas de alojamiento modernas.
Red: integración con ModemManager y nuevas opciones de rendimiento
En la capa de red, systemd-networkd sigue ganando peso. Una de las novedades destacadas es su integración con ModemManager mediante el protocolo “simple connect”, lo que permite gestionar módems y conexiones móviles directamente desde networkd sin depender de herramientas externas.
Para soportar este flujo se añade una nueva sección a los ficheros de configuración, con parámetros como APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=. Esto facilita despliegues en zonas rurales o entornos con conectividad basada en redes móviles, muy presentes en determinados territorios de Europa donde no siempre hay fibra o líneas fijas de calidad.
En el plano de rendimiento, los ficheros .link de systemd-networkd incorporan nuevas opciones específicas para dispositivos Ethernet. Entre ellas encontramos ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList y GenericReceiveOffloadUDPForwarding. Estas opciones permiten afinar la descarga de trabajo al hardware y a los drivers, algo clave en redes corporativas, centros de datos y proveedores de servicios que necesitan apurar cada milisegundo de latencia.
Además, las interfaces Varlink y JSON de systemd-networkd ahora son capaces de informar direcciones IP en un formato legible para humanos (cadenas) a la vez que mantienen la representación como array de enteros. Esto simplifica la integración con paneles de monitorización, scripts de administración o herramientas de terceros que no quieren lidiar con formatos numéricos poco intuitivos.
Portabilidad de servicios, máquinas virtuales efímeras y servicios sin privilegios
La pieza systemd-portabled, encargada de gestionar servicios “portables” empaquetados en imágenes, gana una capacidad muy interesante: puede ejecutarse como servicio a nivel de usuario. Esto significa que usuarios sin privilegios, en su sesión normal, pueden lanzar y gestionar servicios portables dentro de su propio espacio sin recurrir a sudo ni elevar privilegios.
Además, desde esta versión, portabled puede generar políticas y fijar la imagen asociada a un servicio portable, haciendo que esa imagen no pueda modificarse sin volver a adjuntarla. Los usuarios pueden así montar entornos autocontenidos con garantías adicionales de inmutabilidad, algo bastante atractivo para laboratorios, entornos de desarrollo y sandboxes de pruebas.
Por otro lado, systemd-vmspawn —la herramienta pensada para lanzar máquinas virtuales de manera integrada con systemd— amplía sus capacidades para registrarse en systemd-machined dentro de la sesión de usuario. También introduce una opción –ephemeral para crear máquinas efímeras que se destruyen al finalizar su uso. Esto encaja de maravilla con pipelines de CI/CD, aulas virtuales o plataformas educativas europeas que requieren levantar y tirar máquinas de forma rápida y controlada.
Control fino de CPU, memoria y planificación con SCHED_EXT y THP
Systemd 260 también se mete de lleno en el control de rendimiento con nuevas directivas. La opción de servicio CPUSchedulingPolicy= acepta ahora el valor ext, que activa el planificador SCHED_EXT. Este planificador alternativo abre la puerta a experimentos con políticas de planificación distintas a las estándar del kernel, algo que puede interesar en laboratorios de I+D o en despliegues muy especializados.
En el área de memoria aparece MemoryTHP=, que permite gestionar el uso de Transparent Huge Pages (THP) por servicio. En lugar de tener un comportamiento global para todo el sistema, se puede decidir si una unidad determinada debe aprovechar THP, desactivarlas o adoptar modos intermedios. Para aplicaciones críticas en banca, seguros o administraciones públicas, este control granular puede marcar diferencias en latencia, consumo de memoria y rendimiento.
Nuevos comandos en systemctl y expansión del uso de Varlink
El conocido comando systemctl gana una nueva orden: enqueue-marked. Esta acción invoca internamente el método D-Bus EnqueueMarkedJobs() y permite trabajar con colas de trabajos y servicios previamente marcados. Aunque pueda parecer un detalle menor, para equipos de operaciones que orquestan granjas de servidores a gran escala es una herramienta más para afinar flujos de despliegue y automatización.
En paralelo, el proyecto sigue extendiendo el uso de Varlink como mecanismo de comunicación entre componentes. Muchas piezas de systemd exponen interfaces Varlink estables, que facilitan la integración con herramientas externas, dashboards personalizados o agentes de monitorización que necesiten un acceso estructurado a la información del sistema.
Campos de identificación del sistema y experiencia de usuario
Una novedad curiosa, pero útil para algunas distribuciones, es la introducción del campo FANCY_NAME= en el archivo /etc/os-release. Este campo se parece a PRETTY_NAME, pero permite secuencias ANSI y caracteres Unicode más elaborados. Gracias a ello, distribuciones y ediciones específicas pueden presentarse con nombres más vistosos o distintivos.
El valor de FANCY_NAME puede verse a través del gestor de systemd, mediante systemd-hostnamed o al consultar hostnamectl. Aunque es un cambio pequeño, en entornos de escritorio y paneles de administración gráficos puede resultar práctico para identificar de un vistazo el sistema que se está gestionando, especialmente cuando se manejan muchas variantes derivadas.
Documentación específica para agentes de IA y flujo de revisión asistido
Una de las señales más interesantes de por dónde van los tiros en el desarrollo de systemd es la aparición de documentación orientada expresamente a agentes de inteligencia artificial. En el repositorio se incorpora un archivo AGENTS.md, pensado para que herramientas de análisis de código y asistentes de programación, y como recogen algunas guías de tecnología, entiendan mejor la arquitectura del proyecto, su estilo, su flujo de desarrollo y sus normas de contribución.
En este documento se describen componentes, rutas de compilación, forma de ejecutar pruebas e integración y pautas para generar parches aceptables. La intención es que los agentes de IA que revisan código o generan cambios trabajen con un contexto sólido sobre cómo está organizado systemd, reduciendo errores y sugerencias fuera de lugar.
Junto a AGENTS.md aparece un archivo llamado CLAUDE.md, que hace referencia explícita al primero y está enfocado a orientar a la herramienta Claude Code, uno de los asistentes de desarrollo basados en IA más utilizados. De esta manera, el proyecto adopta de forma explícita a la IA en su ciclo de desarrollo.
Además, se incluye un fichero de configuración claude-review.yml, donde se define cómo debe revisarse, con ayuda de Claude Code, el proceso de análisis de solicitudes de cambio (pull requests). En este contexto se exige que las contribuciones que hayan utilizado IA incorporen etiquetas de divulgación como Co-developed-by en los parches, dejando constancia de que una herramienta automática ha participado en la elaboración del código.
Con todo este conjunto de cambios —limpieza de soporte heredado, refinamiento de sandboxing, mejoras en TPM2 y SRK, integración en red avanzada, nuevas capacidades de portabilidad y documentación pensada para agentes inteligentes— systemd 260 refuerza su papel central en el ecosistema Linux moderno. Para administradores y desarrolladores en España y Europa, el reto inmediato pasa por revisar kernels, adaptar configuraciones de arranque y servicios, y sacar partido de estas funciones para construir infraestructuras más seguras, automatizadas y alineadas con los usos actuales del sistema.