Le problème
Sur un système basé sur Linux, le système de fichiers racine se remplit par un processus inconnu. Il continue quels que soient les fichiers déplacés ou nettoyés du système de fichiers.
# df -hP / /dev/mapper/VGExaDb-LVDbSys1 ext3 30G 29G 0 100% /
Il n'y a pas de fichiers volumineux pour représenter le système de fichiers complet :
# find / -xdev -type f -size +100M -exec ls -lh {} \; Il n'y a pas de grands répertoires pour représenter le système de fichiers complet :
# du -h --max-depth=1 / 42M /sbin 13M /etc 2.4G /usr 45M /tmp 451M /var 192M /lib (and so on) ...
La solution
À un moment donné dans le passé, deux processus ou plus utilisaient un fichier ; par exemple,/tmp/top.log. Un processus a arrêté son accès à /tmp/top.log en le supprimant (en fait c'est une entrée de répertoire) et l'autre processus a continué à écrire dans la référence inode, permettant au fichier de continuer à croître.
Cela peut être vu dans la sortie de :"lsof +L 1 ”
# lsof +L 1 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME top 34261 root 1W REG 252,0 21460567592 0 1785896 /tmp/top.log (deleted)
D'autres fichiers étaient également répertoriés mais étaient beaucoup plus petits.
Cela montre que user=root exécutait une commande top qui était mise en file d'attente vers /tmp/top.log, et qu'il n'y a actuellement aucun lien vers ce fichier. Ce fichier spool avait une taille de 21 Go mais n'a pas été signalé dans la sortie « du –h –max-depth=1 / », où /tmp n'était répertorié que comme 45 Mo.
Suivez les étapes ci-dessous pour identifier et tuer un tel processus.
1. Identifiez les fichiers du système qui ont moins d'un lien avec la commande :
# lsof +L 1
2. Arrêtez tous les processus qui écrivent dans un fichier répertorié anormalement volumineux. Dans l'exemple ci-dessus, vous exécuteriez :
# kill 34261
3. L'espace sera libéré lorsque le processus final cessera d'utiliser le fichier.