Je courais Ubuntu, comme d’habitude, quand j’ai soudain eu une boîte de dialog dans laquelle il ne restait que 1,2 Go d’espace libre. Une heure avant, j’avais 30 Go d’espace libre.
J’ai supprimé des éléments et porté l’espace libre à 25 Go. Mais il continue à diminuer. J’ai essayé de supprimer les anciens fichiers journaux et de tronquer les fichiers journaux, etc., et cela continue à diminuer!
J’ai essayé d’utiliser Disk Analyzer pour trouver d’où venait cette perte d’espace libre et qui ne fonctionnait pas, car tout se passait comme il se doit. J’ai redémarré et finalement Ubuntu a effectué une vérification du disque qui a ramené l’espace libre à 40 Go, mais qui continue de diminuer d’environ 10 Go par jour. Je continue d’essayer de trouver de nouveaux moyens de libérer de l’espace, mais c’est comme un processus automatisé de réduction de l’espace disque que je ne parviens pas à arrêter.
Je ne sais pas quoi faire. Comment puis-je trouver la cause et empêcher mon espace libre de diminuer?
Voici la sortie de sudo du -sh /var/* ~/.xsession-errors
:
13M /var/backups 204M /var/cache 112M /var/crash 4.0K /var/games 503M /var/lib 4.0K /var/local 0 /var/lock 9.5G /var/log 85M /var/mail 4.0K /var/mesortingcs 24K /var/opt 0 /var/run 1.7M /var/spool 391M /var/tmp 11G /var/tvmobili 20K /var/www 224K /home/school/.xsession-errors
Vous avez des journaux hors de contrôle. Au lieu de les supprimer tous les jours comme d’habitude, trouvez le ou les fichiers à croissance rapide et examinez l’ intérieur pour en déterminer les causes. Peut-être qu’un programme tourne dans une boucle enregistrant une condition. Désactivez ce programme, désactivez sa journalisation ou essayez de résoudre le problème dont il se plaint.
Si un fichier grandit devant vos yeux et que vous ne savez pas quel programme y écrit, vous pourrez peut-être le découvrir facilement. Voici un exemple. Qui a /var/log/syslog
ouvert? Nous utilisons la commande fuser
:
# fuser /var/log/syslog /var/log/syslog: 602
/var/log/syslog
ouvert dans un seul processus. C’est le processus 602. Qu’est-ce que c’est? Ne nous embêtons pas avec ps
et grep
, mais regardons directement le système de fichiers /proc
:
# ls -l /proc/602/exe lrwxrwxrwx 1 root root 0 Mar 29 17:45 /proc/602/exe -> /usr/sbin/rsyslogd
Aha, c’est rsyslogd
. Nous ne sums pas surpris que rsyslogd
ait /var/log/syslog/
open.
Cette méthode n’est pas garantie au travail. La raison en est que les programmes ne doivent pas garder les fichiers ouverts pour pouvoir y écrire. Supposons que vous ayez un processus qui ouvre un fichier, l’ajoute au fichier, puis le ferme. Vous aurez une enquête un peu plus difficile. Vous pouvez exécuter le fuser
nombreuses fois jusqu’à ce que, par hasard, vous preniez le processus “en flagrant délit”. Ce processus lui-même pourrait entrer et sortir rapidement. Un autre problème est que le fichier peut être ouvert dans plusieurs processus, mais un seul le rend plus volumineux. Dans ce cas, vous pouvez suivre leurs appels système.
# fuser /var/log/huge-annoying-file /var/log/huge-annoying-file: 1234 23459
Oops! Deux processus l’ont ouvert: 1234 et 23459. Voyons ce qu’ils font:
# strace -p 1234 Process 1234 attached - interrupt to quit select(1, NULL, NULL, NULL, {9, 922666}
Il ne fait rien, il se contente de bloquer un appel sélectif. Ctrl-C pour rompre la trace:
select(1, NULL, NULL, NULL, {9, 922666}^C
Vérifiez le prochain:
# strace -p 23459 write(5, "Useless garbage ..."..., 512) = 512 write(5, "More useless garbage ..."..., 512) = 512 write(5, "More useless garbage ..."..., 512) = 512 write(5, "More useless garbage ..."..., 512) = 512 write(5, "More useless garbage ..."..., 512) = 512 write(5, "More useless garbage ..."..., 512) = 512 write(5, "More useless garbage ..."..., 512) = 512 ^C
Oups, celui-ci écrit constamment. Ce doit être le mauvais. Nous pouvons même vérifier que le descripteur de fichier 5 dans lequel le processus écrit est bien le fichier volumineux:
# ls -l /proc/23459/fd/5 lr-x------ 1 root root 64 Apr 3 23:39 /proc/23459/fd/5 -> /var/log/huge-annoying-file
Je ne soupçonne pas que votre système de fichiers est corrompu, mais pour forcer une vérification complète, vous n’avez pas besoin de démarrer un DVD.
Commencez par examiner le paramètre de nombre de assemblys maximum de votre système de fichiers. Identifiez votre partition à l’aide de la commande df. Exemple sur un système Ubuntu que j’ai ici:
# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 18062108 5499320 11645284 33% / udev 392152 4 392148 1% /dev tmpfs 159768 768 159000 1% /run none 5120 0 5120 0% /run/lock none 399416 200 399216 1% /run/shm /dev/sr0 43668 43668 0 100% /media/VBOXADDITIONS_4.1.4_74291
Vous pouvez voir que le système de fichiers /
est monté sur /dev/sda1
. Donc, /dev/sda1
est le périphérique de stockage de la partition racine (et la seule partition de ce système particulier).
Regardons quelques atsortingbuts de ce système de fichiers. C’est sûr à faire, même s’il est monté. La commande crache beaucoup de sortie. Voici un extrait:
$ dumpe2fs /dev/sda1 dumpe2fs 1.42 (29-Nov-2011) Filesystem volume name: Last mounted on: / [ ... SNIP ... ] Last mount time: Fri Mar 29 17:45:18 2013 Last write time: Tue Mar 5 09:08:03 2013 Mount count: 22 Maximum mount count: 22 [ ... SNIP ... ]
Regarde, le nombre de assemblys est égal au nombre de assemblys maximum. La prochaine fois que je redémarrerai, il y aura une vérification du système de fichiers. L’important est que le nombre de assemblys soit une valeur positive. Si le vôtre est égal à zéro, remplacez-le par une valeur positive telle que 22 en utilisant tune2fs -c 22 /dev/whatever
. Zéro signifie qu’une vérification n’est jamais forcée quel que soit le nombre de assemblys de la partition. Les systèmes rarement redémarrés devraient avoir des valeurs basses ici. Un serveur qui tombe en panne une fois par an pourrait probablement utiliser un fsck à chaque redémarrage. Vous pouvez également définir des intervalles de vérification basés sur la date.
Maintenant, pour forcer une vérification, vous pouvez remplacer le nombre réel par un nombre supérieur ou égal au maximum, puis redémarrer. Cela se fait avec C
: tune2fs -C 1234 /dev/whatever
. Maintenant, la partition a l’air d’avoir été montée 1234 fois sans vérification, ce qui est supérieur au maximum d’un ou deux chiffres.
Une vérification du disque a libéré une partie de l’espace, ce qui suggère que ce problème (ou une partie de celui-ci) peut être dû à une corruption du système de fichiers. Si tel est le cas, vous devriez pouvoir libérer davantage d’espace en analysant et en réparant le système de fichiers. Cependant, si la corruption est perpétuelle (ce qui peut être ou non le cas), cela signifie généralement que le disque dur est en train de mourir. Si vos sauvegardes (de vos documents et de tout autre fichier important qu’il serait difficile de remplacer) ne sont pas complètement à jour, veuillez sauvegarder tout ce qui est important maintenant!
Pour vérifier et réparer le disque, il ne peut pas être monté (du moins pas en lecture-écriture). Vous devez donc exécuter l’utilitaire de réparation à partir d’un environnement en direct (CD / DVD live ou USB). Tout d’abord, vous devez connaître le nom de périphérique de la partition contenant vos fichiers.
Par conséquent, dans le système installé , exécutez:
mount | grep ' on / '
(Assurez-vous d’inclure l’espace entre /
et '
.)
Vous obtiendrez quelque chose comme:
/dev/sda8 on / type ext4 (rw,errors=remount-ro)
Le texte qui précède – on
l’exemple de ma machine, /dev/sda8
– est le nom complet du périphérique de votre partition racine ( /
). Écrivez ceci – vous en aurez besoin.
Ensuite, démarrez votre ordinateur à partir d’un CD / DVD de bureau Ubuntu ou d’un lecteur flash USB, comme ce que vous avez utilisé pour installer Ubuntu à l’origine. (S’il s’agit d’un système Wubi installé avec le programme d’installation Windows, veuillez nous en informer. Je ne m’y attendais pas, compte tenu de ce que vous avez signalé, mais si tel est le cas, la procédure sera différente.)
Sélectionnez Essayer Ubuntu sans installer (pas installer Ubuntu ). Lorsque vous obtenez un bureau fonctionnel, appuyez sur Ctrl + Alt + T pour ouvrir une fenêtre de terminal. Puis lancez cette commande:
sudo e2fsck -fkccp /dev/sda8
Mais assurez-vous de remplacer /dev/sda8
par le nom de périphérique complet correct pour votre partition /
, comme vous l’avez obtenu avec la méthode décrite ci-dessus.
Cela peut prendre un peu de temps. Les options c
incluses dans cette commande lui permettent d’parsingr la surface du disque à la recherche d’erreurs ainsi que du système de fichiers (et de marquer les zones défectueuses comme telles afin qu’elles ne soient pas utilisées). Vous pouvez laisser cc
dehors si vous voulez (si vous le faites, vous pouvez aussi laisser k
), mais je vous recommande de les garder.
Vous pouvez être invité à résoudre certains problèmes, si e2fsck
pense qu’il est très probable que tenter de les résoudre puisse entraîner une perte de données. (Le p
fait en sorte qu’il résout tous les problèmes qu’il est confiant qu’il peut résoudre sans causer de complications.)
Je recommande que vous soyez fortement enclin à lui permettre de réparer ce qu’il veut, car vous ne devriez le faire qu’après vous être assuré que vos sauvegardes sont à jour , de toute façon. Si vous voulez qu’il tente même des corrections potentiellement dangereuses sans vous y inviter, remplacez le p
par y
.
Après cela, redémarrez votre système Ubuntu et voyez si l’espace est libéré. Si ce n’est pas le cas ou si le problème persiste, veuillez commenter et modifier votre question afin de fournir des détails.
ce problème a été résolu, c’est le pare-feu qui écrit des tonnes de journaux et de fichiers de codage tvmobili