L’espace disque épuisé est la cause la plus fréquente d’un serveur qui s’arrête sans la moindre malveillance. Le site renvoie 500, la base n’écrit plus, le courrier ne part plus — et df -h annonce pendant ce temps plusieurs gigaoctets libres. Passons en revue les trois cas où cela se produit, et ce qu’il faut savoir de SMART.

Cas un : les inodes sont épuisés

Un système de fichiers dispose de deux ressources limitées : la place pour le contenu et les enregistrements décrivant les fichiers. La seconde s’épuise indépendamment de la première :

df -h
df -i

Si IUse% vaut 100 dans la seconde commande, ce sont les inodes. Il reste de la place, mais il est impossible de créer le moindre fichier, même vide.

Les coupables sont toujours les mêmes : des millions de fichiers minuscules. Les sessions PHP dans /var/lib/php/sessions dont le ramassage est cassé. Un cache applicatif jamais purgé. Une file de courrier bloquée. Un répertoire de vignettes. On les trouve ainsi :

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

La commande liste les répertoires contenant le plus de fichiers. Sur un grand système, elle tourne plusieurs minutes — c’est normal.

Cas deux : le fichier est supprimé, la place n’est pas revenue

Situation plus perfide. Quelqu’un a supprimé un journal démesuré avec rm, mais le processus qui y écrivait le garde ouvert. Le fichier n’est plus dans le répertoire, la place reste occupée, et ce jusqu’au redémarrage du processus.

sudo lsof +L1

La commande montre les fichiers sans référence dans le système de fichiers mais toujours tenus par un processus. Le remède est de redémarrer ou recharger doucement ce processus, non de chercher « où sont passés les gigaoctets ».

D’où la règle : un journal démesuré ne se supprime pas, il se vide — le descripteur ouvert reste alors utilisable :

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

Et aussitôt après, configurez la rotation, sinon tout se répétera en une semaine.

Cas trois : les journaux l’ont dévoré

Où la place est exactement partie se voit en descendant niveau par niveau :

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

L’option -x empêche de partir sur d’autres systèmes de fichiers ; sans elle, le compte s’égare dans /proc et les montages réseau. Tout cela est plus confortable dans ncdu, s’il est disponible.

Les dévoreurs habituels :

  • journald. Une commande tranche : journalctl --disk-usage. On le borne par la ligne SystemMaxUse=500M dans /etc/systemd/journald.conf, et on le purge une fois avec journalctl --vacuum-size=200M ;
  • les journaux des outils de sécurité. Suricata, avec sa configuration par défaut, écrit une trentaine de types d’événements et ne se configure aucune rotation — sur un serveur réel cela a donné 15 Go en deux jours. Il en va de même pour audit.log et pour les journaux de débogage de nginx ;
  • les sauvegardes déposées sur le même disque et jamais supprimées ;
  • le cache d’apt — apt clean rend parfois quelques gigaoctets.

Un mot sur /boot

Une petite partition qui se remplit d’anciens noyaux. Elle ne fait pas tomber le site à elle seule, en revanche elle arrête net les mises à jour : le nouveau noyau ne s’installe pas, et toute la file des paquets se bloque derrière. Se corrige avec apt autoremove --purge, et se prévient en activant la suppression automatique des noyaux inutilisés dans les réglages des mises à jour automatiques.

SMART : quels attributs comptent

Une réserve d’abord : sur un serveur virtuel, SMART est le plus souvent indisponible — le disque est virtuel et vous ne voyez pas le physique en dessous. Ce n’est pas une panne, il n’y a simplement pas de données. Tout ce qui suit concerne les serveurs dédiés et le matériel qui vous appartient.

sudo smartctl -a /dev/sda

La ligne SMART overall-health self-assessment test result: PASSED n’est pas une raison de se détendre : elle reste verte pratiquement jusqu’à la panne. Ce qu’il faut regarder, ce sont les compteurs précis :

  • 5, Reallocated_Sector_Ct — secteurs réalloués. Non nul signifie que le disque se dégrade déjà ; s’il augmente, remplacez-le sans attendre ;
  • 197, Current_Pending_Sector — secteurs illisibles en attente de décision. Le plus alarmant de tous : cela signifie d’ordinaire qu’une partie des données est déjà irrécupérable ;
  • 198, Offline_Uncorrectable — la même chose, confirmée par une vérification ;
  • SSD : Percentage Used / Media_Wearout_Indicator — l’endurance en écriture consommée. Une grandeur prévisible, sur laquelle on planifie un remplacement.

La température et les heures de fonctionnement, en revanche, ne disent rien par elles-mêmes : un disque avec cinq ans de service et des compteurs d’erreurs à zéro est plus fiable qu’un neuf avec un 1 dans l’attribut 197.

Le sens de la surveillance

Tout ce qui précède est une réaction à ce qui est déjà arrivé. Or le remplissage d’un disque comme l’usure d’un SSD sont des processus lents et parfaitement prévisibles : une courbe d’occupation sur deux semaines donne la date à laquelle la place manquera bien avant que cela n’arrive. La différence entre « le site est tombé à trois heures du matin » et « jeudi il faudra nettoyer les journaux » tient uniquement au fait d’avoir le chiffre sous les yeux. À quoi cela ressemble une fois rassemblé, la page de démonstration ci-dessous le montre.