Comment puis-je arrêter cette perte constante d'espace libre?

J'utilisais Ubuntu, comme d'habitude, quand soudain j'ai eu une boîte de dialogue qui disait qu'il ne me restait que 1,2 Go d'espace libre. Une heure auparavant, j'avais 30 Go d'espace libre.

J'ai supprimé des trucs et porté l'espace libre à 25 Go. Mais il continue de diminuer. J'ai essayé de supprimer les anciens fichiers journaux et de tronquer les fichiers journaux et autres, et cela continue de diminuer!

J'ai essayé d'utiliser Disk Analyzer pour trouver d'où provenait toute cette perte d'espace libre et cela n'a pas fonctionné, car il montrait tout comme il se doit. J'ai redémarré et finalement Ubuntu a fait une vérification du disque qui a en quelque sorte ramené l'espace libre à 40 Go, mais il continue de diminuer d'environ 10 Go par jour. Je continue d'essayer de trouver de nouvelles façons de libérer de l'espace, mais c'est comme un processus automatisé de diminution de l'espace disque que je n'arrive pas à arrêter.

Je ne sais pas quoi faire. Comment puis-je trouver la cause et empêcher que mon espace libre ne diminue?

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/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 comme des fous tous les jours, 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 corriger la condition dont il se plaint.

Si un fichier se développe sous 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/syslogouvert? Nous utilisons la fusercommande:

# fuser /var/log/syslog
/var/log/syslog:      602

Un seul processus s'est /var/log/syslogouvert. C'est le processus 602. Qu'est-ce que c'est? Ne nous occupons pas de pset grep, mais regardons /procdirectement le système de fichiers:

# ls -l /proc/602/exe
lrwxrwxrwx 1 root root 0 Mar 29 17:45 /proc/602/exe -> /usr/sbin/rsyslogd

Aha, ça l'est rsyslogd. Nous ne sommes pas surpris que cela se rsyslogdsoit /var/log/syslog/ouvert.

Cette méthode n'est pas garantie de fonctionner. La raison en est que les programmes n'ont pas besoin de garder les fichiers ouverts pour pouvoir y écrire. Supposons que vous ayez un processus qui ouvre un fichier, y ajoute, puis le ferme. Vous aurez une enquête un peu plus difficile. Vous pouvez exécuter fuserplusieurs fois jusqu'à ce que vous preniez par hasard le processus "en flagrant délit". Ce processus lui-même pourrait entrer et disparaître rapidement. Un autre problème est que plusieurs processus peuvent ouvrir le fichier, mais un seul le rend plus grand. Dans ce cas, vous pouvez suivre leurs appels système.

# fuser /var/log/huge-annoying-file
/var/log/huge-annoying-file:   1234 23459

Oups! 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 bloque simplement un selectappel. Ctrl-C pour casser la trace:

select(1, NULL, NULL, NULL, {9, 922666}^C <unfinished ...>

Vérifiez le suivant:

# 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-là écrit constamment. Ce doit être le mauvais. On peut même vérifier que le descripteur de fichier 5 sur lequel le processus écrit est bien le gros fichier:

# 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 vous ayez un système de fichiers corrompu, mais pour forcer une vérification complète, vous n'avez pas besoin de démarrer un DVD.

Tout d'abord, passez en revue le paramètre de nombre maximal de montages 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. Il en /dev/sda1va de même du périphérique de stockage de la partition racine (et de la seule partition de ce système particulier).

Examinons 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. En 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 ... ]

Hé, regardez, 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 nul, changez-le en une valeur positive comme 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 fois où la partition est montée. Les systèmes rarement redémarrés devraient avoir des valeurs faibles 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 pour être supérieur ou égal au maximum, puis redémarrer. Cela se fait avec le capital C: tune2fs -C 1234 /dev/whatever. Maintenant, la partition semble avoir été montée 1234 fois sans vérification, ce qui est supérieur au maximum à un ou deux chiffres.

Une vérification du disque a libéré une partie de l'espace, suggérant 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 plus d'espace en analysant et en réparant le système de fichiers. Cependant, si la corruption se produit perpétuellement (ce qui pourrait ou non être 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 qui seraient difficiles à 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 ou USB en direct). Tout d'abord, vous devrez trouver le nom de l'appareil de la partition qui contient vos fichiers.

Par conséquent, dans le système installé , exécutez:

mount | grep ' on / '

(Assurez-vous d'inclure l'espace entre le /et '.)

Vous obtiendrez quelque chose comme:

/dev/sda8 on / type ext4 (rw,errors=remount-ro)

Le texte avant on- dans l'exemple de ma machine, /dev/sda8- est le nom complet de l'appareil pour votre partition racine ( /). Notez cela - vous en aurez besoin.

Ensuite, démarrez votre ordinateur à partir d'un CD / DVD de bureau Ubuntu ou d'une clé 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 de Windows, veuillez nous le faire savoir. Je ne m'attends pas à ce que, 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+ Tpour ouvrir une fenêtre de terminal. Exécutez ensuite cette commande:

sudo e2fsck -fkccp /dev/sda8

Mais assurez-vous de remplacer /dev/sda8par le bon nom complet de périphérique pour votre /partition, comme vous l'avez obtenu par la méthode détaillée ci-dessus.

Cela peut prendre un peu de temps. Les coptions incluses dans cette commande lui permettent d'analyser la surface du disque pour les erreurs ainsi que le système de fichiers (et de marquer toutes les zones défectueuses comme mauvaises afin qu'elles ne soient pas utilisées). Vous pouvez laisser de cccôté si vous le souhaitez (si vous le faites, vous pouvez également laisser de côté k), mais je vous recommande de les garder.

Vous pouvez être invité à résoudre certains problèmes, si vous e2fsckpensez qu'il existe une forte probabilité que tenter de les résoudre puisse entraîner une perte de données. (Le pfait en sorte qu'il résout tous les problèmes qu'il est sûr de pouvoir résoudre sans causer de complications.)

Je vous recommande d'être 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 souhaitez qu'il essaie même des correctifs potentiellement dangereux sans vous y inviter, remplacez le ppar 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 pour fournir des détails.

ce problème a été résolu, c'était le pare-feu qui écrivait des tonnes de journaux et des fichiers d'encodage tvmobili