Comment puis-je arrêter cette perte constante d'espace libre?
J'utilisais Ubuntu, comme d'habitude, quand une boîte de dialogue m'indique que je ne dispose que de 1,2 Go d'espace libre. Une heure avant, j'avais 30 Go d'espace libre.
J'ai supprimé des éléments et apporté de l'espace libre jusqu'à 25 Go. Mais il continue à diminuer. J'ai essayé de supprimer les anciens fichiers journaux et de les tronquer, 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 permis de ramener 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 le résultat 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/metrics
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 supprimer chaque jour comme un fou, trouvez le ou les fichiers à croissance rapide et regardez à l’intérieur pour rechercher la cause de ce problème. 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
Un seul processus a ouvert /var/log/syslog. 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 sommes pas surpris que rsyslogd ait /var/log/syslog/ ouvert.
Cette méthode n'est pas garantie pour fonctionner. 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 fuser plusieurs 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 processus peut être ouvert dans plusieurs processus, mais un seul le rend plus gros. 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 select. Ctrl-C pour casser la trace:
select(1, NULL, NULL, NULL, {9, 922666}^C <unfinished ...>
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 pense pas que votre système de fichiers soit corrompu, mais pour forcer une vérification complète, vous n'avez pas à démarrer un DVD.
Commencez par examiner le paramètre de nombre de montages 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 attributs 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: <none>
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 montages est égal au nombre de montages 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 montages 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 montages 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 majuscule 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 devrez connaître le nom de périphérique de la partition contenant vos fichiers.
Par conséquent, sur 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 précédant on-- dans l'exemple de ma machine, _/dev/sda8_-- est le nom complet du périphérique de votre partition racine (_/_). Ecrivez 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 Essayez Ubuntu sans installer (pas Installez Ubuntu ). Lorsque vous obtenez un bureau fonctionnel, appuyez sur Ctrl+Alt+T 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étaillée ci-dessus.
Cela peut prendre un peu de temps. Les options c incluses dans cette commande lui permettent d'analyser 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 si vous le souhaitez (si vous le faites, vous pouvez également laisser de côté k), mais je vous recommande de les conserver.
Vous serez peut-être invité à résoudre certains problèmes si _e2fsck_ pense qu'il est très probable que le fait de tenter de les résoudre puisse entraîner la perte de données. (La p permet de résoudre tous les problèmes qu’elle est confiante de pouvoir résoudre sans causer de complications.)
Je recommande que vous soyez fortement enclin à lui permettre de réparer ce qu'il veut, puisque vous ne devriez le faire que après en vous assurant que vos sauvegardes sont en cours, 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