systemd 258 retira definitivamente de cgroup v1 y pasa a requerir Linux 5.4 como mínimo

systemd 258 llega cargado de cambios que afectan al arranque, a la seguridad, a la gestión de sesiones y a la administración diaria en Linux. Es una versión con miga: simplifica tecnologías clave del kernel y retira compatibilidad heredada que muchas distribuciones aún arrastraban, a la vez que añade utilidades nuevas pensadas para escenarios reales.

Si trabajas con servidores, estaciones de trabajo o entornos de contenedores, conviene ponerse al día. Desde la retirada definitiva de cgroup v1 hasta un mínimo de kernel más exigente, pasando por ajustes de permisos en TTY, cambios en systemd-logind y novedades como systemd-factory-reset o systemd-pty-forward, esta versión no es una actualización cualquiera.

Adiós a cgroup v1: solo cgroup v2 a partir de ahora

Lo más sonado del lanzamiento es la eliminación completa del soporte para cgroup v1. Se acabó el modo legacy o híbrido: a partir de systemd 258, durante el arranque se monta exclusivamente cgroup v2, y lo mismo ocurre en los contenedores gestionados con systemd-nspawn. Este cambio simplifica la pila de control de recursos del kernel y reduce superficies de ataque y ambigüedades de configuración.

¿Por qué importa? cgroup v2 unifica el modelo de control de CPU, memoria, I/O y más en una jerarquía coherente, evitando inconsistencias del pasado. Desde hace más de dos años se venía avisando de este movimiento, de modo que no pilla por sorpresa; aun así, puede impactar a quienes aún usaban configuraciones antiguas o dependían de herramientas que no se adaptaron a v2.

Requisito de kernel en systemd 258: mínimo 5.4, recomendado 5.7

Junto a esa limpieza, systemd 258 establece un kernel mínimo soportado de Linux 5.4 y sugiere como recomendado 5.7. Este salto deja atrás ramas más viejas: en la práctica, es responsabilidad de cada distribución ofrecer kernels compatibles, pero si mantenías sistemas con versiones anteriores tendrás que planificar una actualización del kernel para seguir al día con systemd.

Además de habilitar funcionalidades modernas, un kernel reciente suele traer mejoras de seguridad y rendimiento, algo que encaja con el objetivo de esta versión: homogeneizar comportamientos y reducir casos límite difíciles de mantener.

Seguridad: permisos TTY más restrictivos y criptografía unificada

En el terreno de la seguridad, systemd 258 endurece por defecto el acceso a dispositivos TTY/PTS. Los nodos creados pasan a tener permisos 0600 en lugar de 0620, impidiendo que otros usuarios escriban en la terminal. Esta medida corta de raíz varias situaciones molestas y potencialmente peligrosas en entornos multiusuario.

También hay unificación en las dependencias de cifrado: systemd-resolved y systemd-importd ahora soportan exclusivamente OpenSSL. Se deja fuera GnuTLS y libgcrypt en estos componentes, simplificando la matriz de compatibilidad y evitando duplicidades. Si en tus compilaciones o políticas de distro dabas por hecho GnuTLS o libgcrypt, toca revisarlo.

Gestión de sesiones: tareas en segundo plano reclasificadas

Otra novedad clave está en systemd-logind. A partir de esta versión, ciertas tareas en segundo plano como cron o sesiones FTP se reclasifican bajo nuevas categorías ‘light’. ¿Qué implica? Que ya no se arrancará un gestor de servicios completo para ellas salvo que se configure explícitamente. Para el usuario final no cambia gran cosa, pero para administración y auditoría es importante tenerlo presente por el efecto en la contabilidad de sesiones y el consumo de recursos.

systemd 258 retira el soporte heredado: fin de los scripts System V

El proceso de limpieza continúa: se eliminan definitivamente los scripts de inicio al estilo System V. Junto con ellos desaparecen comandos clásicos como initctl o telinit. Es un paso esperado y coherente con la realidad del ecosistema Linux actual, donde systemd ha sustituido a los mecanismos previos en la mayoría de distros.

En esa misma línea se retiran vías tradicionales como /forcefsck y /fastboot. En su lugar, la recomendación pasa por usar parámetros de kernel o credenciales para indicar estas operaciones. Menos magia y más configuración transparente y auditable.

Nuevas herramientas: factory reset y reenvío de PTY

systemd 258 incorpora utilidades interesantes orientadas a vida real. La más destacada es systemd-factory-reset, que permite solicitar o cancelar un reseteo completo a valores de fábrica directamente desde espacio de usuario. Esto es oro en laboratorios, appliances o entornos de servidores donde hace falta volver a un estado limpio de manera controlada.

Junto a ella aparece systemd-pty-forward, una herramienta para asignar y reenviar pseudo-terminales (PTY). Resulta práctica para automatización, depuración y para gestionar procesos en segundo plano que necesitan vincularse a un TTY de forma segura y flexible.

Arranque, UKIs y TPM2: cambios que preparan el terreno

En el apartado de arranque, hay mejoras en systemd-boot y, especialmente, cambios relevantes en la integración con TPM2. Desde ahora, las políticas ya no dependen por defecto del PCR 7, lo que modifica la manera en que se gestionan claves y políticas para arranques verificados. Este ajuste reduce ataduras a mediciones concretas y da margen a esquemas de seguridad más adaptables.

Además, se pulen los UKIs (Unified Kernel Images). En esta versión, los UKIs pueden embeber imágenes de firmware UEFI, facilitando la distribución de paquetes de arranque autocontenidos y mejorando la cadena de confianza. Para administradores que trabajan con arranques verificados, secure boot y despliegues reproducibles, este refinamiento es especialmente interesante.

Compatibilidad de systemd 258 y administración: qué debes revisar

Con todo lo anterior, hay varias tareas de comprobación sensatas. Por un lado, verifica el kernel en tus sistemas: si estás por debajo de 5.4, deberías planificar una actualización; si puedes, mejor aún subir a 5.7 o superior para alinearte con la recomendación del proyecto.

Por otro lado, comprueba dependencias criptográficas si mantenías builds con GnuTLS o libgcrypt para los componentes afectados. Y si tenías aún restos de scripts System V integrados en tu flujo, migra a unidades nativas de systemd con dependencias bien declaradas; ganarás en trazabilidad y mantenimiento a largo plazo.

Atención: resolved, DNSSEC y el caso Pi-hole

Hay una incidencia práctica que conviene destacar: si usas un servidor de nombres que no implemente DNSSEC (por ejemplo, Pi-hole tal cual viene de fábrica), actualizar a systemd 258-2 puede romper la resolución. No es un bug del todo ‘misterioso’: al exigir validación DNSSEC, resolved fallará cuando el servidor upstream no soporte esa característica.

Hay dos maneras sencillas de solucionarlo, dependiendo de tu preferencia:

1. Desactivar DNSSEC en systemd-resolved: edita /etc/systemd/resolved.conf, añade o descomenta la línea DNSSEC=no, guarda cambios y reinicia el servicio con systemctl restart systemd-resolved. Es la vía rápida si controlas el host y necesitas restablecer resolución cuanto antes.
2. Activar DNSSEC en Pi-hole: entra en la interfaz de Pi-hole y habilita DNSSEC en Configuración -> Configuración DNS avanzada. Si tu upstream soporta DNSSEC, esta opción te permite mantener la validación y seguir beneficiándote de la seguridad adicional.

Como siempre, elige la alternativa que encaje con tu topología. En redes domésticas o laboratorios, desactivar temporalmente DNSSEC puede ser pragmático; en producción, activar soporte DNSSEC de extremo a extremo es la opción preferente.

Ajustes de permisos y multiusuario: TTY más seguros en systemd 258

Volviendo a los permisos TTY, no es moco de pavo: pasar de 0620 a 0600 corta la posibilidad de que otros usuarios escriban en tu terminal, incluso en situaciones donde los grupos daban pie a interacciones inesperadas. Si tienes flujos que dependían de ese comportamiento laxo, te tocará ajustarlos para que usen canales explícitos de IPC, tmux compartido o soluciones similares, en lugar de confiar en escribir en un TTY ajeno.

Más cambios de systemd 258: udev, networkd, journalctl y limpieza general

Como en cada versión, hay muchos ajustes menores repartidos entre udev, networkd, journalctl y otras piezas. Se retiran opciones obsoletas, se pulen mensajes, se corrigen esquinas de comportamiento y se añaden validaciones. Aunque cueste verlos uno por uno, la suma de estas pequeñas mejoras contribuye a una experiencia más coherente y predecible.

Si te interesa el detalle fino, las notas de lanzamiento en GitHub son el sitio. Ojo, son técnicas y densas; aun así, para integradores y distribuidores, merece la pena revisarlas para detectar cambios que puedan afectar a CI/CD, scripts de empaquetado o políticas corporativas.

Mirando a la siguiente versión: preparando el salto

Este lanzamiento también sirve de antesala: systemd 259 planea elevar requisitos en el sistema, lo que podría impactar a hardware y entornos muy antiguos. La señal es clara: toca reducir lastre heredado y apostar por caminos soportables a largo plazo. Migrar ahora a cgroup v2 y asegurar kernels modernos te pondrá en buena posición para lo que viene.

Buenas prácticas de migración y comprobaciones

Para quienes aún vivían en híbrido o legacy, una lista de comprobación no viene mal. Valida que tus contenedores y servicios trabajan bien con cgroup v2; la mayoría de orquestadores y herramientas modernas ya lo soportan, pero no des por hecho los defaults. Revisa unidades con directivas de recursos (CPUQuota, MemoryMax, etc.) y comprueba su efecto real bajo v2.

En seguridad, audita servicios que dependían de TTY compartidos. Si había automatizaciones que abrían la puerta a escribir en terminales de otros usuarios, redirígelas a métodos claros y con control de permisos. Y si mantenías integración con bibliotecas de cifrado fuera de OpenSSL para los componentes afectados, ajusta tu toolchain de compilación.

Preguntas frecuentes rápidas

• ¿Puedo seguir usando scripts System V? No con systemd 258. Migra a unidades nativas y elimina dependencias de initctl o telinit.
• ¿Qué pasa si mi kernel es anterior a 5.4? systemd 258 no lo soporta. Actualiza el kernel; si no es posible, no podrás adoptar esta versión.
• ¿Me afecta el cambio de permisos TTY? En entornos multiusuario sí: revisa workflows que escriban en TTY ajenos y cámbialos por mecanismos explícitos.
• ¿Debo activar DNSSEC? Si puedes, sí. Si tu servidor DNS upstream no lo soporta, desactívalo en resolved o habilítalo en Pi-hole para evitar cortes.

Queda claro que systemd 258 es una versión de calado: homogeneiza cgroup v2, eleva el listón del kernel, refuerza la seguridad y añade herramientas útiles como el reseteo a fábrica y el reenvío de PTY. Trae además cambios en boot, UKIs y TPM2 que allanan el camino para futuros requisitos, y no se corta en retirar legado como los scripts System V. Con una revisión rápida de kernel, dependencias de cifrado, permisos y DNS, la transición resulta bastante asequible incluso en entornos exigentes.