Ubuntu 26.10 cambia cosa chiudere quando finisce la RAM: il desktop viene prima

Quando la RAM finisce, Linux deve prendere una decisione poco piacevole: scegliere quale processo sacrificare per evitare che l’intero sistema rimanga bloccato. Su desktop, però, eliminare il processo sbagliato può essere persino peggio di chiudere un’applicazione affamata di memoria. Ubuntu 26.10 modifica proprio questo comportamento, introducendo una nuova politica per proteggere meglio componenti essenziali come GNOME Shell e D-Bus quando la pressione sulla memoria diventa critica.

Linux dispone da molti anni di un proprio meccanismo Out Of Memory (OOM), mentre dal kernel 4.20 sono disponibili anche le metriche PSI, Pressure Stall Information, pensate per quantificare quanto CPU, memoria e I/O stiano rallentando concretamente i processi. systemd ha poi aggiunto systemd-oomd portando nello spazio utente un secondo livello di gestione preventiva della memoria. La combinazione offre parecchi strumenti, ma rende anche più delicato stabilire quali processi vadano terminati per primi.

Canonical ha deciso di intervenire con Ubuntu 26.10, nome in codice “Stonking Stingray“: il cambiamento, illustrato dall’Ubuntu Desktop Team, interessa soprattutto la stabilità della sessione grafica in presenza di carichi molto pesanti, poca RAM o swap limitata. Il sistema può sopravvivere alla chiusura di un browser o di una macchina virtuale; perdere GNOME Shell o D-Bus (sistema di comunicazione che permette a processi, applicazioni e servizi Linux di scambiarsi messaggi e richieste), invece, può rendere inutilizzabile l’intera sessione.

Come funziona la chiusura dei processi a livello di kernel Linux

Ogni processo in esecuzione su Linux espone attraverso /proc/PID/oom_score un valore che indica quanto sia “appetibile” come vittima dell’OOM killer, il meccanismo utilizzato dal kernel per scegliere quali oggetti “sacrificare” in caso di pressante necessità.

Gli amministratori e i servizi possono modificare tale preferenza attraverso oom_score_adj. Come documenta la pagina del manuale Linux dedicata oom_score_adj, l’intervallo ammesso va da -1000 a +1000: numeri negativi proteggono il processo, mentre quelli positivi aumentano la probabilità che possa essere terminato. Il valore -1000 rappresenta il caso estremo e sottrae sostanzialmente il processo alla normale selezione dell’OOM killer.

Nel calcolo reale dell’OOM score, come abbiamo spiegato nel nostro articolo citato in precedenza, il kernel non guarda soltanto alla correzione configurata dall’amministratore: considera anche memoria residente, pagine presenti nella swap, page table e dimensione dell’insieme di memoria. Per questo oom_score_adj funziona come un correttivo molto potente, non come una classifica assoluta scritta una volta per tutte.

Il problema individuato da Canonical nasce proprio dalla somma delle decisioni prese nel corso del tempo da applicazioni, servizi e componenti desktop. Alcuni processi della sessione utente risultavano più esposti di quanto fosse desiderabile su una workstation grafica.

Ubuntu 26.10 cambia la gerarchia delle vittime

La nuova impostazione di Canonical, al debutto con Ubuntu 26.10, parte da un principio difficilmente contestabile: quando la memoria è davvero esaurita, è preferibile perdere un’applicazione piuttosto che l’intera sessione grafica.

I servizi desktop considerati critici ricevono quindi un OOM score più basso. GNOME Shell, D-Bus e altri componenti indispensabili hanno meno probabilità di finire nel mirino del kernel, mentre normali applicazioni e servizi in background mantengono valori più alti. Canonical descrive esplicitamente questa gerarchia nella nuova politica OOM di Ubuntu 26.10.

OOM killer resta una misura d’emergenza e la scelta dipende dall’utilizzo della memoria, dai limiti applicati, dai cgroup (meccanismo del kernel Linux che raggruppa i processi per limitarne e monitorarne l’uso di risorse come memoria, CPU e I/O) e dai valori di correzione assegnati ai processi.

La nuova politica applicata da Canonical cerca però di rendere l’ordine dei processi più “papabili” per essere arrestati maggiormente sensato su un sistema desktop.

Proteggere GNOME Shell non risolve magicamente l’esaurimento della RAM; riduce piuttosto la probabilità che la cura faccia più danni del problema originale.

Canonical interviene anche su systemd-oomd

Ubuntu non si affida soltanto all’OOM killer interno al kernel: è presente anche systemd-oomd, un daemon che prova a intervenire prima che la situazione degeneri completamente.

I due meccanismi non funzionano allo stesso modo. L’OOM killer del kernel entra in gioco quando il sistema raggiunge una vera condizione di memoria insufficiente e utilizza, tra gli altri elementi, oom_score_adj. systemd-oomd lavora invece sui cgroup e sulle informazioni PSI, cercando di riconoscere una pressione eccessiva sulla memoria prima che il kernel arrivi alla “scelta estrema”.

Ed è qui che Ubuntu 26.10 introduce la seconda modifica rilevante: Canonical disabilita l’azione automatica di systemd-oomd che poteva terminare l’intera sessione utente sulla base della sola pressione della memoria.