Systemd 260 elimina SysV y redefine el arranque en Linux

La llegada de systemd 260 marca un punto de inflexión para el ecosistema Linux. Esta nueva versión del sistema de inicio y gestor de servicios más extendido en las distribuciones modernas viene cargada de cambios profundos, algunos de ellos rompedores, que afectan tanto a la compatibilidad con software heredado como a la forma de gestionar la seguridad, la red, los contenedores y hasta la propia integración con agentes de IA. Si administras servidores o trabajas con Linux a diario, es una de esas versiones que conviene mirar con lupa.

Más allá de los titulares, el gran protagonista es la retirada definitiva del soporte para los clásicos scripts de SysV init, lo que cierra una etapa histórica en Linux y obliga a revisar servicios antiguos. Junto a ese movimiento, systemd 260 introduce nuevas utilidades, incrementa los requisitos mínimos de kernel, mejora la integración con TPM2, refuerza el aislamiento de servicios, amplía las capacidades de red y contenedores y pule muchos detalles pensados para entornos de escritorio, servidores y despliegues cloud.

Fin del soporte a SysV init: qué cambia en la práctica

Una de las novedades más sonadas de systemd 260 es la eliminación completa de la compatibilidad con scripts de arranque estilo System V, los típicos guiones almacenados en /etc/init.d/ que durante años han sido la base del inicio de servicios en Linux. Ese soporte llevaba tiempo etiquetado como obsoleto y se avisaba de que acabaría desapareciendo; ahora ese momento ha llegado.

Con esta versión, los componentes encargados de traducir scripts SysV a unidades systemd han sido retirados. Desaparecen piezas como systemd-sysv-generator, que generaba unidades «al vuelo» a partir de /etc/init.d, y también systemd-sysv-install, además de otros elementos de compatibilidad como systemd-rc-local-generator y rc-local.service, que daban soporte al clásico /etc/rc.local.

Este movimiento implica que cualquier servicio que todavía dependa únicamente de scripts SysV dejará de iniciarse correctamente en cuanto la distribución adopte systemd 260, a menos que se haya creado una unidad nativa .service. En infraestructuras modernas el impacto será relativamente bajo, pero en entornos con software antiguo o desarrollado a medida puede haber más de una sorpresa si no se hace una auditoría previa.

En paralelo, algunas opciones del sistema de construcción Meson relacionadas con SysV han sido marcadas como obsoletas o eliminadas. Parámetros como -Drc-local=, -Dsysvinit-path= y -Dsysvrcnd-path= quedan como deprecated, mientras que opciones como -Dintegration-tests= y -Dcryptolib= directamente desaparecen del árbol de compilación, simplificando la base de código.

En términos operativos, esto también significa que systemd pasa a centrarse exclusivamente en unidades nativas, sin capas intermedias ni generación automática de servicios desde scripts viejos. El mensaje es bastante claro: si algo importante en tu sistema aún vive como un script en /etc/init.d/, es el momento de migrarlo de forma explícita.

Por qué se ha eliminado SysV: limpieza técnica y futuro del ecosistema

La decisión de borrar del mapa la compatibilidad con SysV init no es un capricho. Desde el punto de vista del proyecto, mantener código heredado para un mecanismo de inicio prácticamente en desuso era un lastre que complicaba el mantenimiento y la evolución del framework. El soporte de compatibilidad llevaba años considerado legado, y su uso real en distribuciones principales era cada vez más marginal.

Al retirar esta capa, systemd reduce la complejidad interna y elimina rutas de ejecución difíciles de probar y asegurar. Con menos caminos especiales para tratar servicios antiguos, el equipo de desarrollo puede centrarse en pulir el motor principal de unidades nativas, mejorar la seguridad, el rendimiento y la integración con las nuevas APIs del kernel y del espacio de usuario.

También hay un componente claro de alineación con los estándares actuales en gestión de servicios. Hoy prácticamente todas las grandes distribuciones Linux han abrazado systemd como sistema de inicio principal y ofrecen unidades nativas para sus paquetes. Mantener SysV como muleta era, en la práctica, sostener un modelo de arranque que ya no encajaba con la forma moderna de describir dependencias, cgroups, logs estructurados y controles de recursos.

Desde la óptica del rendimiento, eliminar capas de compatibilidad permite recortar algo de sobrecarga y evitar transformaciones innecesarias en tiempo de arranque. Aunque el impacto en milisegundos no sea dramático, en sistemas muy afinados o con muchos servicios puede ayudar a mantener un comportamiento más predecible; además, conviene saber cómo modificar el tiempo de espera del menú de arranque para pruebas y validaciones.

Para los administradores de sistemas, el mensaje práctico es que SysV es ya historia en entornos basados en systemd. Toca asumir que el modelo de referencia son las unidades .service, junto con el resto de tipos de unidad (sockets, timers, targets, etc.), y adaptar las herramientas internas, documentación y formación a esa realidad.

Cómo comprobar si tu sistema aún depende de SysV y qué hacer

Antes de que tu distribución salte a systemd 260, es muy recomendable revisar si sigues teniendo servicios que dependen de scripts clásicos. La comprobación básica pasa por listar el contenido de /etc/init.d/, donde tradicionalmente residen estos guiones de inicio:

ls /etc/init.d/

Si ves ahí scripts que no tienen su equivalente en /etc/systemd/system o en las rutas típicas de unidades, es una señal clara de que hay trabajo pendiente. No basta con que el script exista: lo importante es si todavía se usa para arrancar o detener servicios en la práctica.

Otro truco útil es buscar unidades generadas a partir de SysV en versiones anteriores de systemd. Aunque en la 260 ya no existan, te puede servir en sistemas actuales para identificar qué se rompiera tras la actualización:

systemctl list-unit-files | grep generated

Si esa orden muestra servicios marcados como «generated», normalmente provienen de scripts heredados. Conviene localizarlos y planificar su sustitución por unidades nativas, preferiblemente antes de que el salto de versión llegue a producción.

En cuanto a la migración, una aproximación rápida consiste en envolver temporalmente el script SysV dentro de una unidad systemd, especificando en ExecStart y ExecStop las llamadas al script con argumentos start y stop. No es la solución más elegante, pero te permite ganar tiempo mientras reescribes el servicio de forma más idiomática.

A medio plazo, lo recomendable es definir unidades que llamen directamente al binario o al comando principal del servicio, aprovechando directivas modernas como Restart=, límites de recursos, integración con cgroups y opciones avanzadas de sandboxing, en lugar de seguir dependiendo de scripts legacy llenos de lógica específica.

Nuevas capacidades y cambios técnicos clave en systemd 260

Aunque el adiós a SysV se lleva buena parte de la atención, systemd 260 viene con un buen puñado de novedades adicionales que tocan seguridad, red, kernel, contenedores, portabilidad de servicios y hasta la forma de presentar la información del sistema. Es una versión especialmente densa en cambios internos, pensada para seguir aprovechando las capacidades de kernels recientes.

Uno de los puntos importantes es el aumento de la versión mínima de kernel soportada. Systemd 260 ya no se ejecuta en núcleos tan viejos como Linux 5.4: la versión mínima pasa a ser Linux 5.10. Además, el propio proyecto recomienda usar al menos Linux 5.14, y señala que un kernel 6.6 es la opción ideal si se quieren exprimir todas las funcionalidades presentes en esta release.

Esta subida de requisitos no es trivial, porque obliga a dejar atrás distribuciones o entornos que sigan anclados a kernels muy antiguos, habituales en ciertos despliegues empresariales o embebidos. A cambio, permite a systemd apoyarse en APIs más modernas del kernel, explotar mejor cgroups v2, nuevas políticas de planificación y mejoras de seguridad que simplemente no existen en series más viejas.

En paralelo, se ha añadido un nuevo campo FANCY_NAME= en el fichero /etc/os-release. Este campo es similar al ya conocido PRETTY_NAME, pero con la particularidad de que puede incluir secuencias ANSI y caracteres especiales, como emojis. Systemd manager, systemd-hostnamed y la herramienta hostnamectl pueden mostrar este valor para ofrecer una presentación más vistosa de la distribución, especialmente en interfaces interactivas o herramientas de diagnóstico.

Más allá de lo cosmético, systemd 260 continúa profundizando en el uso de Varlink como mecanismo de comunicación y API, extendiendo su presencia en distintos componentes. Esto facilita la interacción programática con el sistema, la integración con herramientas externas y, en general, una forma más estructurada de consultar y modificar el estado de servicios y recursos.

También hay mejoras en áreas como la gestión de recursos basada en cgroups v2, optimizaciones en tiempos de arranque, una mejor integración con contenedores y máquinas virtuales y refinamientos en el manejo de logs mediante journald, aunque muchos de estos cambios son incrementales y se notan más en despliegues grandes o muy afinados.

Seguridad y aislamiento: TPM2, PrivateUsers y nuevas políticas de memoria

En el frente de la seguridad, systemd 260 avanza en varios frentes. Por un lado, se refuerza la integración con TPM2, el módulo de plataforma segura presente en muchas placas base UEFI y dispositivos modernos. Estos chips se utilizan, entre otras cosas, para proteger claves de cifrado y automatizar el desbloqueo de discos o particiones en el arranque.

Concretamente, udev incorpora ahora un nuevo builtin llamado tpm2_id, que permite extraer e identificar de forma automática el fabricante y modelo de los dispositivos TPM2 conectados durante la fase de detección de hardware. Esta información puede usarse después para políticas de seguridad más específicas, scripts de auditoría o herramientas de inventario que quieran saber exactamente qué TPM tiene cada máquina.

Otra mejora importante llega con la implementación completa de PrivateUsers=full, una opción de aislamiento que permite mapear el rango completo de IDs de usuario dentro de un servicio. Este cambio elimina la solución de compromiso que se usaba para detectar correctamente instancias anidadas de systemd basadas en versiones anteriores a la 257, simplificando el comportamiento cuando hay contenedores o entornos anidados.

Para quienes no estén familiarizados, PrivateUsers es una funcionalidad de sandboxing que aísla el espacio de usuarios de un servicio, de forma que procesos en su interior vean un mapa de UIDs diferente al del sistema host. Esto refuerza el aislamiento frente a escaladas de privilegios y ayuda a limitar el impacto de vulnerabilidades en servicios concretos.

Además, systemd 260 introduce una nueva directiva de servicio llamada MemoryTHP=, que permite controlar el uso de Transparent Huge Pages (THP) a nivel de unidad. Las THP pueden mejorar el rendimiento en ciertas cargas de trabajo intensivas en memoria, pero también generar problemas en otras. Tener una perilla específica para activarlas, desactivarlas o ajustar su comportamiento por servicio ayuda a afinar mucho más el rendimiento sin tener que aplicar políticas globales.

Novedades en systemd-logind, systemd-udevd y control de acceso a dispositivos

En el ámbito de la gestión de sesiones y dispositivos, systemd 260 añade un concepto interesante llamado «xaccess», implementado en systemd-logind y systemd-udevd. Hasta ahora existía la lógica de «uaccess», que concedía permisos a dispositivos (por ejemplo, una webcam o un dispositivo de entrada) a usuarios con sesiones en primer plano en la consola local.

El nuevo mecanismo xaccess permite delegar el acceso a dispositivos concretos a sesiones marcadas de forma especial, incluso cuando los usuarios no están físicamente delante de la máquina. El caso de uso típico es otorgar acceso a dispositivos de renderizado de GPU a sesiones gráficas locales empleadas por usuarios remotos, que no tienen un asiento físico asociado.

La configuración de estas sesiones se realiza mediante la variable de entorno PAM XDG_SESSION_EXTRA_DEVICE_ACCESS=, que indica qué dispositivos adicionales se deben conceder a la sesión bajo esta lógica. Esto complementa a uaccess y da más flexibilidad en escenarios de escritorio remoto, virtualización ligera, laboratorios compartidos o acceso gráfico a distancia.

En general, estos cambios apuntan a un control más fino y dinámico de quién puede acceder a qué hardware, sin tener que recurrir únicamente a grupos estáticos o permisos globales. Es especialmente útil en equipos multiusuario o en servidores con GPU compartidas, donde se quiere equilibrar seguridad y comodidad.

systemd-networkd y ModemManager: redes móviles y nuevas opciones de enlace

En el terreno de la red, systemd 260 trae mejoras interesantes. La más llamativa es que systemd-networkd se integra ahora con ModemManager mediante el protocolo «simple connect», lo que facilita la gestión de conexiones de datos móviles (3G, 4G, 5G) directamente desde la configuración de systemd.

Para ello se ha introducido una nueva sección en los archivos de configuración de networkd, que acepta parámetros como APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=. Esto permite definir de forma declarativa cómo debe levantarse la conexión móvil, qué credenciales usar y qué comportamiento seguir en itinerancia, entre otros aspectos.

Además, systemd-networkd amplía las opciones disponibles en los ficheros .link para configurar interfaces Ethernet. Entre las nuevas directivas se encuentran ajustes de capacidades como ScatterGather=, ScatterGatherFragmentList=, TCPECNSegmentationOffload=, TCPMangleIdSegmentationOffload=, GenericReceiveOffloadList= y GenericReceiveOffloadUDPForwarding=, que permiten un control mucho más detallado de las optimizaciones de red a bajo nivel.

Otra mejora notable es que las interfaces Varlink y JSON de systemd-networkd ahora pueden reportar direcciones IP en formato de cadena legible por humanos, además del formato de array de enteros que ya existía. Esto facilita bastante la vida a herramientas externas y scripts que consultan el estado de la red, evitando conversiones engorrosas.

En conjunto, estos cambios refuerzan la posición de systemd-networkd como gestor de red capaz de abarcar desde configuraciones básicas de servidor hasta escenarios avanzados con redes móviles, ajustes finos de offloading en NICs modernas e integración con APIs externas como ModemManager.

Contenedores, portabilidad de servicios y nuevas herramientas

En el terreno de la virtualización ligera y los contenedores, systemd 260 introduce varias mejoras relevantes. Una de las más destacadas es la incorporación de un nuevo comando de línea llamado systemd-mstack, pensado para trabajar de forma interactiva con la nueva funcionalidad «mstack».

La característica mstack permite definir un OverlayFS estructurando el contenido de un directorio .mstack/ siguiendo una especificación concreta. Esta capacidad se enmarca dentro del esfuerzo de systemd por ampliar sus herramientas de contenedorización y sandboxing, incluyendo soporte para descargar y gestionar imágenes OCI a través de systemd-importd. En esencia, hace más fácil montar pilas de capas de sistema de archivos sin depender exclusivamente de herramientas externas.

También se han introducido mejoras en systemd-vmspawn, la herramienta orientada a lanzar máquinas virtuales de forma integrada con systemd. Entre las novedades, destaca el soporte para registrar máquinas en systemd-machined dentro de la sesión de usuario, así como la posibilidad de crear máquinas efímeras mediante la opción --ephemeral, que desaparecen una vez terminan su trabajo.

En cuanto a systemd-portabled, responsable de gestionar servicios portables basados en imágenes, ahora gana la capacidad de ejecutarse como servicio a nivel de usuario. Esto significa que usuarios sin privilegios de administrador pueden lanzar y gestionar servicios portables en su propio espacio, siempre que estén usando un kernel suficientemente reciente y la distribución haya habilitado esta opción.

Además, systemd-portabled puede ahora generar una política y fijar la imagen usada para los servicios portables, bloqueando su modificación posterior mientras no se vuelva a adjuntar. Esto aporta un plus de integridad y confianza en entornos donde se quiera garantizar que la imagen que se está ejecutando no cambia de forma silenciosa.

Mejoras en systemctl, planificación de CPU y documentación para IA

En la interfaz de administración de servicios, systemctl incorpora en esta versión un nuevo verbo llamado enqueue-marked, que llama internamente al método D-Bus EnqueueMarkedJobs(). Esta función está orientada a gestionar de forma más precisa los trabajos marcados en la cola de systemd, dando más control a herramientas avanzadas y scripts de automatización.

También aparece una mejora en la parte de planificación de CPU: la directiva CPUSchedulingPolicy= admite ahora el valor ext, que permite habilitar el planificador SCHED_EXT. Este nuevo tipo de scheduling, todavía emergente en el ecosistema Linux, ofrece más flexibilidad para cargas de trabajo especiales y sistemas que quieran experimentar con políticas externas de planificación.

Un detalle curioso pero significativo es que el proyecto ha añadido documentación específica para agentes de IA dentro del repositorio de systemd. El objetivo es ayudar a bots y scrapers basados en inteligencia artificial a entender mejor el código, el estilo de programación, las guías de contribución y el funcionamiento interno del proyecto, reduciendo malinterpretaciones comunes.

Ligado a esto, el equipo de systemd exige que las contribuciones generadas con ayuda de IA incluyan una etiqueta de transparencia, como el tag co-developed-by en los parches, de forma que quede constancia de que se ha utilizado este tipo de herramientas en la elaboración del código. Es una muestra de cómo incluso un proyecto tan de bajo nivel se está adaptando a la realidad de la IA generativa.

Por último, systemd-repart añade soporte para realizar comprobaciones básicas de integridad en volúmenes cifrados, lo que resulta útil en despliegues donde se trabaja con particiones o imágenes protegidas y se quiere validar su estado sin recurrir a utilidades externas más complejas.

Impacto en distribuciones y recomendaciones para usuarios

En cuanto al despliegue real de systemd 260, la versión empezará a llegar progresivamente a las grandes distribuciones a lo largo del primer semestre en que se integre, normalmente a través de ramas de desarrollo o ediciones rolling release. Distros como Arch Linux u openSUSE Tumbleweed suelen adoptar estas versiones con bastante rapidez.

En cambio, las distribuciones de ciclo fijo y ediciones LTS suelen tardar más en incorporar una versión mayor de systemd, especialmente si el cambio rompe compatibilidad con tecnología heredada como SysV init. Proyectos como Fedora, por ejemplo, acostumbran a no actualizar la versión mayor de systemd dentro del mismo ciclo de una release estable, sino que reservan esos cambios para versiones nuevas de la distribución.

Para el usuario medio de escritorio, la actualización de systemd rara vez se siente como algo crítico, ya que las distribuciones se encargan de empaquetar todo para que nada «explote». Sin embargo, siempre hay entusiastas que quieren tener lo último a toda costa, y en esos casos es mejor apostar por distribuciones rolling o repositorios de pruebas, asumiendo el riesgo.

En entornos de producción, la recomendación es clara: auditar los servicios legacy, revisar scripts en /etc/init.d/, probar la migración a unidades systemd nativas en entornos de staging y validar muy bien el comportamiento antes de desplegar en máquinas críticas. Saltarse ese paso puede traducirse en servicios que no arrancan, fallos en cadenas de arranque cifradas o problemas de red en configuraciones avanzadas.

En definitiva, systemd 260 supone un gran salto hacia un ecosistema Linux más homogéneo y moderno, pero también obliga a dejar atrás prácticas y componentes que llevaban décadas entre nosotros. Quien se adelante y planifique la transición tendrá una experiencia mucho más tranquila cuando las distribuciones den el paso y esta versión se convierta en la nueva base de sus sistemas.