Introducción
Un desarrollador abre cuarenta y dos pestañas en Firefox, un build de Rust consume 6 GB de RAM, y el sistema entra en presión de memoria. El kernel evalúa qué proceso sacrificar. Elige GNOME Shell. La sesión entera se cae al login screen, se pierden terminales con procesos corriendo, se cierran IDEs sin guardar. El problema no es la falta de RAM: es que el OOM killer no distingue entre una pestaña de navegador y el compositor que mantiene viva toda la sesión gráfica.
Ubuntu 26.10, con fecha de lanzamiento el 15 de octubre de 2026 (beta disponible desde el 24 de septiembre), introduce cambios en la asignación de puntajes OOM y restringe la acción de systemd-oomd sobre sesiones de usuario. Jean Baptiste Lallement, ingeniero de Canonical detrás de la implementación, resume el objetivo: «preservar la sesión de escritorio donde sea posible» terminando aplicaciones antes que servicios core del entorno gráfico. Para equipos de infraestructura que soportan flotas de workstations Linux o administran entornos de desarrollo en Ubuntu, esto modifica directamente los runbooks de recuperación ante OOM.
Qué ocurrió
El OOM killer del kernel Linux opera sobre un modelo simple: cuando no hay memoria disponible y no se puede liberar mediante swap o reclaim, el kernel recorre los procesos y termina el que tenga el oom_score más alto. Ese puntaje se calcula a partir del consumo de memoria relativo al total del sistema. El problema estructural es que, por defecto, Firefox y GNOME Shell comparten la misma categoría de prioridad. No hay una jerarquía semántica que le diga al kernel «esto es el compositor, esto es una app del usuario».
En la práctica, cuando la presión crece, el OOM killer puede seleccionar GNOME Shell como víctima porque su footprint de memoria lo coloca en la misma franja que una app que está haciendo memory leak. El resultado: el usuario pierde la sesión completa, no solo la pestaña problemática. Lallement reporta que reproduce este escenario con frecuencia en VMs de Ubuntu donde abre múltiples pestañas de Firefox simultáneamente.
Canonical aborda esto con dos cambios concretos en Ubuntu 26.10. Primero, baja los oom_score_adj de los procesos del entorno de escritorio (GNOME Shell, mutter, gnome-session) para que queden fuera del rango de selección del OOM killer frente a aplicaciones. Segundo, deshabilita la capacidad de systemd-oomd de matar sesiones de usuario, porque su mecanismo de puntuación no es equivalente al del kernel y podía eliminar servicios críticos del escritorio basándose en umbrales de presión que no respetaban la jerarquía de prioridad ajustada.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de infraestructura que gestionan flotas de workstations Ubuntu en entornos corporativos, este cambio reduce la tasa de tickets de soporte por «se me cayó el escritorio». No elimina los OOM events, pero cambia cuál proceso termina y, por lo tanto, cuál es el costo operativo del incidente. Un tab de Firefox que se cae es un evento de usuario sin intervención de infraestructura. Un GNOME Shell que se cae requiere re-login, re-spawn de sesiones de X/Wayland, y potencialmente re-conexión de credenciales de vault o tokens de sesión.
En entornos donde se corre systemd-oomd con políticas customizadas para servidores de desarrollo compartidos o jump hosts con sesiones gráficas, la restricción sobre sesiones de usuario obliga a revisar las reglas de SwapUsedLimit y DefaultMemoryPressureThresholds en los drop-ins de oomd.conf. Si la política actual depende de que systemd-oomd mate procesos dentro del slice user.slice, Ubuntu 26.10 va a ignorar esas acciones para sesiones interactivas.
Para cloud y SRE, el impacto es acotado: la mayoría de workloads en instancias EC2, GCP o Azure no corren sesiones de escritorio. Sin embargo, equipos que usan Ubuntu como base para workstations en VDI (Citrix, VMware Horizon, o soluciones basadas en xrdp) y configuran systemd-oomd a nivel de usuario deben auditar sus drop-ins antes de migrar a 26.10.
Detalles técnicos
El mecanismo del kernel se controla vía /proc/[pid]/oom_score (valor calculado por el kernel) y /proc/[pid]/oom_score_adj (ajuste manual, rango -1000 a +1000). Ubuntu 26.10 aplica un oom_score_adj negativo a los procesos de GNOME Shell y mutter, desplazándolos fuera del rango donde el OOM killer opera normalmente. Un servicio con oom_score_adj = -500 prácticamente nunca será seleccionado como víctima a menos que el sistema esté en condiciones extremas.
systemd-oomd opera sobre cgroups v2 y usa métricas de presión de memoria (memory.pressure) con umbrales configurables en /etc/systemd/oomd.conf. El problema que Canonical identifica es que systemd-oomd no consulta los oom_score_adj del kernel al tomar decisiones dentro de user.slice. Matar procesos en esa jerarquía de cgroup puede eliminar gnome-shell o mutter aunque el kernel los haya protegido con puntajes bajos. La solución en 26.10 es un filtro que impide que systemd-oomd actúe sobre procesos de sesión interactiva.
Para verificar el estado actual en un sistema Ubuntu existente, podés inspeccionar los puntajes con:
# Ver oom_score_adj de gnome-shell (requiere root)
cat /proc/$(pgrep gnome-shell)/oom_score_adj
# Ver el oom_score calculado por el kernel
cat /proc/$(pgrep gnome-shell)/oom_score
# Ver políticas de systemd-oomd activas
systemctl status systemd-oomd
cat /etc/systemd/oomd.conf
En Ubuntu 26.10, el oom_score_adj de los procesos core del escritorio debería reportar un valor negativo (típicamente -500 o similar según la implementación final en la beta). Los procesos de aplicaciones del usuario quedan en 0 o positivo, lo que los coloca como candidatos prioritarios para terminación.
Lallement es explícito: esto es «un primer paso» que «no hace a Ubuntu inmune a condiciones OOM». Canonical planea políticas OOM más granulares para servicios de escritorio y aplicaciones en releases posteriores. No hay fecha confirmada para esa segunda iteración.
Qué deberían hacer los administradores y equipos técnicos
Si gestionás flotas de workstations Ubuntu que van a migrar a 26.10, revisá primero si tenés drop-ins de systemd-oomd que operen sobre user.slice:
# Buscar drop-ins customizados de oomd
find /etc/systemd/ -name «*.conf» | xargs grep -l «oom» 2>/dev/null
grep -r «SwapUsedLimit\|DefaultMemoryPressureThresholds» /etc/systemd/oomd.conf.d/
Si esas reglas dependen de que systemd-oomd termine procesos dentro de sesiones de usuario, necesitás reescribirlas para que operen sobre system.slice o app.slice explícitamente, excluyendo user.slice. Para entornos VDI con xrdp, verificá que las sesiones de usuario no estén mapeadas a un cgroup que systemd-oomd todavía pueda alcanzar.
En servidores de desarrollo donde corre GNOME (raro pero existente), confirmá que no haya cron jobs o scripts de monitoring que reescriban oom_score_adj de los procesos de escritorio. Un echo 0 > /proc/$(pgrep gnome-shell)/oom_score_adj en un script heredado anula la protección de Canonical.
Para monitoreo, instrumentá eventos OOM con journalctl -k | grep -i «out of memory» y correlacioná con oomd en el journal. Si después de migrar a 26.10 seguís viendo terminaciones de gnome-shell, algo está sobrescribiendo los puntajes o systemd-oomd está operando sobre un cgroup que no respeta la nueva jerarquía.
Conclusión
Ubuntu 26.10 no resuelve el OOM. Resuelve un problema de jerarquía: el kernel y systemd-oomd ya no van a matar el compositor para salvar una pestaña. Para equipos de infraestructura, el cambio es operativo y bajo riesgo, pero requiere auditar configuraciones customizadas de systemd-oomd que asuman que el daemon puede actuar libremente sobre user.slice. La beta del 24 de septiembre es el momento de validar esas reglas antes de que 26.10 llegue a producción en flotas completas.
Fuentes
- OMG Ubuntu: https://www.omgubuntu.co.uk/2026/09/ubuntu-memory-oomd-changes