L'espace disque est insuffisant, d'où vient-il ?

Je pense que quelque chose écrit dans un fichier qui a été supprimé du disque mais qui n'a pas encore été fermé par l'application/serveur, de sorte que l'espace reste alloué sur le disque mais ne peut pas être vu par du depuis que le fichier a été retiré du système de fichiers. Le fichier lsof répertorie les processus dont les fichiers sont ouverts. Si vous aviez plus de systèmes de fichiers montés et que le nombre ne fluctuait pas autant, j'aurais suggéré que vous aviez un système de fichiers monté au-dessus d'un répertoire qui n'était pas vide (bien que vous puissiez essayer umount /var/lib/ureadahead/debugfs et assurez-vous que ce répertoire est vide et qu'il n'y a pas un tas de saletés écrites dans le répertoire caché sous ce point de montage).

Si c'est le cas, vous devriez les trouver facilement auprès de sudo lsof | grep deleted . lsof comprend (deleted) dans la dernière colonne si un fichier a été supprimé alors qu'un processus l'a encore ouvert. La première colonne est le nom de la commande, la seconde le PID. Vous pouvez obtenir un aperçu plus détaillé de la commande en utilisant ps par exemple ps auxww | grep PID ou ps auxwwf | less -S pour voir la liste des processus en mode "forêt" afin de savoir de quel processus provient le PID. Une fois que vous avez identifié le(s) processus qui maintiennent des fichiers géants ouverts, vous pouvez l'arrêter pour libérer de l'espace sur le disque, puis trouver comment le réparer pour qu'il ferme le fichier correctement. La cause habituelle de ce problème est un script script de logrotate qui renomme/supprime les fichiers journaux mais ne notifie pas l'application qu'il l'a fait (soit par un signal approprié avec la commande kill ou en redémarrant l'application), de sorte que l'application continue à maintenir l'ancien fichier journal ouvert.

Exécuter

du -h --max-depth=1 /

Et cela devrait donner une image plus claire. Si cela va et vient, il semble que des fichiers temporaires soient créés et ne soient pas supprimés une fois qu'ils ont été utilisés, jusqu'à ce que le processus qui en est à l'origine se bloque. Quel est le système d'exploitation de ce serveur et utilise-t-il quelque chose de particulier ?

Il semble que le problème soit /var/lib/ureadahead/debugfs . Il semble qu'il s'agisse d'un problème connu, voici un lien vers ubuntuforums avec plus d'informations http://ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrading-to-ubuntu-10-04 . L'essentiel semble être de mettre à jour et de mettre à niveau, sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabled puis redémarrer. Bien entendu, je suppose que vous utilisez la version 10.04.

Je pense que ce sont les fichiers journaux ; j'avais tellement d'avertissements PHP 5.3 "deprecated" dans mes journaux Apache sur un serveur de développement auquel je ne prêtais pas vraiment attention que cela a grignoté les 8 Go d'espace sur ma partition var (en marge du problème : vous devriez toujours placer /var sur une partition séparée de votre partition racine car manquer d'espace peut causer des problèmes d'instabilité du système).

Si l'espace a été consommé très rapidement (pas en quelques années), il s'agit probablement d'une simple allocation de fichier.

La cause peut être un énorme swap ou des fichiers temporaires pour une application, qui sont vidés après le processus.

Faire un du --max-length=1 lorsque l'espace est fortement consommé.

Si vous pensez que votre dossier racine prend trop de place (3.3 GB), essayez de ll -a / et de publier les résultats.