Lo spazio esaurito è la causa più frequente per cui un server smette di funzionare senza alcuna malizia di mezzo. Il sito restituisce 500, il database non scrive, la posta non esce, e df -h intanto segnala diversi gigabyte liberi. Passiamo in rassegna i tre casi in cui questo accade e, già che ci siamo, ciò che conviene sapere su SMART.

Caso uno: sono finiti gli inode

Un file system conserva due risorse limitate: lo spazio per il contenuto e le registrazioni sui file. La seconda si esaurisce indipendentemente dalla prima:

df -h
df -i

Se IUse% nel secondo comando è 100, la questione riguarda gli inode. Lo spazio c’è, ma non si può creare un solo file, neppure vuoto.

I colpevoli sono sempre gli stessi: milioni di file minuscoli. Le sessioni PHP in /var/lib/php/sessions con la raccolta rotta. Una cache applicativa mai svuotata. Una coda di posta bloccata. Una cartella di miniature. Si trovano così:

sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

Il comando elenca le cartelle con il maggior numero di file. Su un sistema grande impiega minuti: è normale.

Caso due: il file è cancellato e lo spazio non è tornato

Situazione più insidiosa. Qualcuno ha cancellato con rm un registro fuori misura, ma il processo che vi scriveva lo tiene ancora aperto. Il file non è più nella cartella, lo spazio resta occupato, e sarà così fino al riavvio del processo.

sudo lsof +L1

Il comando mostra i file senza riferimenti nel file system ma ancora trattenuti da un processo. La cura è riavviare o ricaricare con delicatezza quel processo, non cercare «dove sono finiti i gigabyte».

Da qui la regola: un registro fuori misura non si cancella, si svuota, così il descrittore aperto resta utilizzabile:

sudo truncate -s 0 /var/log/huge.log

E subito dopo si configura la rotazione, altrimenti tutto si ripeterà entro una settimana.

Caso tre: se lo sono mangiato i registri

Dove sia finito esattamente lo spazio si vede scendendo livello per livello:

sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -h

L’opzione -x impedisce di sconfinare su altri file system; senza di essa il conteggio si infila in /proc e nei montaggi di rete. Tutto ciò è più comodo in ncdu, se disponibile.

I divoratori abituali:

  • journald. Un comando risolve: journalctl --disk-usage. Si limita con la riga SystemMaxUse=500M in /etc/systemd/journald.conf e si ripulisce una volta con journalctl --vacuum-size=200M;
  • i registri degli strumenti di sicurezza. Suricata con la configurazione standard scrive trenta tipi di eventi e non si configura alcuna rotazione: su un server reale ciò ha prodotto 15 GB in due giorni. Lo stesso vale per audit.log e per i registri di debug di nginx;
  • i backup depositati sullo stesso disco e mai rimossi;
  • la cache di apt: apt clean a volte restituisce un paio di gigabyte.

Due parole su /boot

Una piccola partizione che si riempie di kernel vecchi. Da sola non fa cadere il sito, in compenso ferma di netto gli aggiornamenti: il kernel nuovo non si installa e dietro si blocca l’intera coda dei pacchetti. Si risolve con apt autoremove --purge e si previene attivando la rimozione automatica dei kernel inutilizzati nelle impostazioni degli aggiornamenti automatici.

SMART: quali attributi contano

Prima una precisazione: su un server virtuale SMART di solito non è disponibile, perché il disco è virtuale e quello fisico sotto lei non lo vede. Non è un guasto, semplicemente non ci sono dati. Tutto ciò che segue riguarda server dedicati e hardware proprio.

sudo smartctl -a /dev/sda

La riga SMART overall-health self-assessment test result: PASSED non è un motivo per rilassarsi: resta verde praticamente fino al guasto. Vanno guardati i contatori specifici:

  • 5, Reallocated_Sector_Ct: settori rimappati. Diverso da zero significa che il disco si sta già degradando; se cresce, lo sostituisca senza rinviare;
  • 197, Current_Pending_Sector: settori illeggibili in attesa di decisione. Il più allarmante di tutti: di solito significa che parte dei dati non è più recuperabile;
  • 198, Offline_Uncorrectable: lo stesso, confermato da una verifica;
  • SSD: Percentage Used / Media_Wearout_Indicator: la resistenza in scrittura consumata. Una grandezza prevedibile, su cui si pianifica la sostituzione.

Temperatura e ore di funzionamento, invece, da sole non dicono nulla: un disco con cinque anni di servizio e contatori di errore a zero è più affidabile di uno nuovo con un 1 nell’attributo 197.

Il senso della sorveglianza

Tutto quanto sopra è una reazione a ciò che è già accaduto. Eppure sia il riempimento di un disco sia l’usura di un SSD sono processi lenti e perfettamente prevedibili: una curva di occupazione su due settimane indica la data in cui lo spazio finirà molto prima che accada. La differenza fra «il sito è giù dalle tre di notte» e «giovedì bisogna ripulire i registri» sta solo nell’avere la cifra davanti agli occhi. Come appare tutto riunito lo mostra la pagina dimostrativa qui sotto.