df dit que le disque est plein, mais il ne l'est pas.

J'ai eu ce problème et j'ai été déconcerté par le fait que la suppression de plusieurs gros fichiers n'a pas amélioré la situation (je ne connaissais pas le tampon de 5 %).

De la racine vers le bas les plus grands répertoires révélés en faisant répétitivement:-

du -sh */ 

jusqu'à ce que je tombe sur un répertoire pour les fichiers journaux des serveurs web qui contenait des journaux absolument énormes

que j'ai tronqué avec

:>lighttpd.error.log

soudainement, df -h était descendu à 48% d'utilisation !

df -h est d'arrondir les valeurs. Même les pourcentages sont arrondis. Omettez le -h et vous voyez des différences plus fines.

Oh. Et ext3 et ses dérivés réservent un pourcentage (par défaut 5%) pour le système de fichiers pour exactement cette constellation problématique. Si votre système de fichiers racine serait vraiment plein (0 octet restant), vous ne pourriez pas démarrer le système. Donc la partie réservée empêche cela.

Si vous manquez d'espace sur /dev/shm et je me demande pourquoi (étant donné que l'espace réel utilisé ( df -shc /dev/shm ) est beaucoup plus petite que /dev/shm taille allouée) ? lsof peut vous aider :

$ sudo lsof -s +L1 | awk '{print $7" "$2" "$3" "$10}' | grep 'dev/shm' | grep "^[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]" 
7931428864 1133806 roel /dev/shm/1600335920/subreducer/2/data/ibtmp1
12710576128 1133806 roel /dev/shm/1600335920/subreducer/2/tmp/#sql-temptable-114cee-8-e18.MAD
4173332480 1352445 roel /dev/shm/1600335920/subreducer/1/data/ibtmp1
13040484352 1352445 roel /dev/shm/1600335920/subreducer/1/tmp/#sql-temptable-14a2fd-8-eb3.MAD
9670602752 2298724 roel /dev/shm/1600338626/subreducer/2/tmp/#sql-temptable-231364-8-d2e.MAD

Le premier fichier consomme environ 7,9 Go, le second environ 12,7 Go, etc. L'expression rationnelle détecte tout ce qui est de 1 Go et plus. Vous pouvez ajuster la regex selon vos besoins. La cause pourrait être qu'un processus autrement mort s'accroche à un fichier. df -h ne montrera pas le problème ;

Filesystem      Size  Used Avail Use% Mounted on
tmpfs            90G   90G  508K 100% /dev/shm

508K, et pourtant...

$ du -shc | grep total
46G total

Vous pouvez voir le décalage 90G <> 46G. C'est dans les fichiers ci-dessus.

Ensuite, il suffit de tuer le PID (kill -9 PID) listé dans la deuxième colonne de la sortie ci-dessus.

$ kill -9 1133806

Résultat :

Filesystem      Size  Used Avail Use% Mounted on
tmpfs            90G   72G   19G  80% /dev/shm

Super, la place est libre.

La raison pour laquelle on fait les choses de cette façon et pas seulement quelque chose comme sudo lsof +L1 | grep '(deleted)' | grep 'dev/shm' | awk '{print $2}' | sudo xargs kill -9 c'est que le ou les processus sous-jacents peuvent encore fonctionner. Si vous êtes sûr qu'il(s) ne fonctionne(nt) pas, cette commande est une alternative potentielle en fonction de votre scénario. Elle tuera tous les processus qui ont des fichiers "supprimés" ouverts.

J'ai fait une grosse mise à jour de plusieurs bibliothèques et il y avait beaucoup de bibliothèques inutiles et de fichiers temporels donc j'ai libéré de l'espace dans le dossier "/" en utilisant :

apt-get install -f
sudo apt-get clean

Et videz votre poubelle

Vérifiez le /lost+found, j'avais un système (centos 7) et certains fichiers dans le /lost+found prenaient tout l'espace.