Bonjour, j'ai un petit problème de fuite d'espace disque sur ma partition / :
typiquement, un "df /" au boot m'indique 3 Go de libres, un jour plus tard c'est 2 Go, etc (à vitesse pas constante) jusqu'à ce qu'il n'y ait plus rien de libre.
Du coup, j'ai des problèmes pour télécharger des mails, installer des programmes, etc, jusqu'à ce que je reboote et que mes 3Go reviennent.
Il s'agit d'une partition ext3 sur laquelle j'ai pas constaté de problèmes (mais je sais pas trop avec quels outils checher quel genre de problème...).
J'ai vérifié que le problème venait pas d'un log trop actif, en faisant des "du -sx /*" je constate que presque rien ne change, et j'ai configurer logrotate pour qu'il s'occupe des logs les plus utilisés, pour être sûr.
J'a aussi regardé si des fichiers étaient supprimés mais toujours ouverts ; "lsof +L1" me montre divers fichiers (/var/run/ssl_mutex ouvert par différents processus apache2, quelques trucs dans /tmp ouverts par mysqld, mais tous ces fichiers sont vides ; plus deux trucs dans /var/tmp, ouverts par firefox et kio_files, qui font ensemble moins de 2Mo), je ne sais pas ce qu'ils foutent là ni comment m'en débarrasser, mais ils n'ont pas l'air d'être ce qui me pose problème.
Es-ce que quelqu'un a une explication ? Je sais que c'est normal que du indique moins d'espace occupé que df, par contre n'indique aucun changement alors que df si ça me dépasse... Merci.
Forum Linux.général Espace disque qui disparaît
1
avr.
2009
# ah, une coincidence?
Posté par GG (site web personnel) . Évalué à 2.
Tu peux éventuellement regarder par là:
https://linuxfr.org/forums/15/26980.html
A bientôt
Grégoire
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# poisson d'avril !!!!!!
Posté par djibb (site web personnel) . Évalué à 1.
# Fichiers ouverts, puis supprimé et ré-écrit
Posté par Olivier (site web personnel) . Évalué à 1.
des tests que tu as fait, le scénario suivant me paraît possible :
- une application, disons Apache2, écrit des logs dans /var/log/appache/access.log
- tu supprimes ce fichier (ou le mécanisme de rotation de logs le supprime). Comme il est encore ouvert, l'espace disque n'est pas libéré
- l'application, ou plus exactement un autre thread en re-ouvre un
- tu regardes ce contenu, et tu constates qu'il est plus ou moins vide
- seul un arrêt complet de tout les processus Apache2 permettra de libérer effectivement l'espace libre. C'est ce qui est fait au reboot
Solution :
- arrête un à un tout les services et les programmes de ta machine, et regarde quand est-ce que l'espace disque se remet à croître
Autre idée :
- Cela peut-être le fait de Xorg qui génère un fichier avec le stdout des applications
- Regarde du coté du /home/$USER/.xsession-errors
- Ou dans le /tmp/, les fichiers "*xsessions*"
- Certaines applications X ont tendance à générer BEAUCOUP de stdout, et elles sont sauvées dans ces fichiers
Solution 2 :
- chez moi, j'ai tout simplement empêcher Xorg de sauver les stdout des applications X
- dans le /etc/X11/Xsession , remplace le
exec >>"$ERRFILE" 2>&1
par :
exec >>/dev/null 2>&1
[^] # Re: Fichiers ouverts, puis supprimé et ré-écrit
Posté par dawan . Évalué à 1.
Comme j'ai pas toujours eu ce problème, j'ai dégagé tous les scripts de démarrage que je pense avoir activé récemment (plus d'autres comme apache2, mysql, etc., pour être sûr), ça a tenu environ 6 heures sans bouger et puis ça a recommencé, 800 Mo disparus en 24 heures sans que du ne dise rien, sans fichiers supprimés et ouverts (autres que ce truc temporaire bizarre de firefox qui reste stable à 28 Mo dans /var/tmp)... et il y avait pas grand chose dans les xsession-errors, et de toutes façons /home est sur une autre partition.
M'enfin, je vais continuer à supprimer des trucs, c'est juste un peu saoulant de devoir attendre 6 heures après chaque boot pour savoir si ça va mieux ou pas. Et je me demande toujours comment un fichier pourrait être réécrit mais effacé sans que ça se voit avec lsof...
[^] # Re: Fichiers ouverts, puis supprimé et ré-écrit
Posté par Olivier (site web personnel) . Évalué à 1.
il y a une autre méthode, mais c'est assez spéciale à mettre en oeuvre :
- Le kernel Linux a une fonctionnalité qui permet de surveiller TOUT les accès en écriture de la machine
- En faisant un echo 1 > /proc/sys/vm/block_dump, le "/var/log/syslog" va se remplir de lignes indiquant quelle application à lut/écrit des données
- Evidement, ce mécanisme remplit lui aussi le disque. Mais si tu le fais sur une période assez courte, tu sauras ce qu'il se passe sur ta machine. Et tu peux commencer par attendre 6h pour surveiller ton disque.
Exemple chez moi :
# echo 1 > /proc/sys/vm/block_dump
# tail -f /var/log/syslog
Apr 6 23:29:57 xxxxx kernel: [ 1686.532306] rsyslogd(2684): dirtied inode 238822 (debug) on hda9
Apr 6 23:29:57 xxxxx kernel: [ 1686.532329] rsyslogd(2684): dirtied inode 238822 (debug) on hda9
Apr 6 23:29:57 xxxxx kernel: [ 1686.532346] rsyslogd(2684): dirtied inode 238822 (debug) on hda9
Apr 6 23:29:59 xxxxx kernel: [ 1688.409057] ls(2685): READ block 3366368 on hda9
Apr 6 23:29:59 xxxxx kernel: [ 1688.833144] ls(2685): READ block 3145960 on hda9
Apr 6 23:29:59 xxxxx kernel: [ 1688.847247] ls(2685): READ block 3267504 on hda9
Apr 6 23:29:59 xxxxx kernel: [ 1688.847336] ls(2685): READ block 3267512 on hda9
Apr 6 23:29:59 xxxxx kernel: [ 1688.847365] ls(2685): READ block 3267520 on hda9
[^] # Re: Fichiers ouverts, puis supprimé et ré-écrit
Posté par dawan . Évalué à 1.
Merci quand même, je note l'astuce du /proc/sys/vm/block_dump, ça peut toujours servir.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.