Forum Linux.général Espace disque qui disparaît

Posté par .
Tags : aucun
1
1
avr.
2009
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.
  • # ah, une coincidence?

    Posté par (page perso) . Évalué à 2.

    Bonjour

    Tu peux éventuellement regarder par là:
    https://linuxfr.org/forums/15/26980.html

    A bientôt
    Grégoire
  • # poisson d'avril !!!!!!

    Posté par (page perso) . Évalué à 1.

    il est pas sympa ton disque dur !!
  • # Fichiers ouverts, puis supprimé et ré-écrit

    Posté par (page perso) . Évalué à 1.

    Bonjour,

    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 . Évalué à 1.

      Merci pour vos réponses.
      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 (page perso) . Évalué à 1.

        Bonjour,

        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 . Évalué à 1.

          Finalement, c'était aucun des services style mysql, et je penche plutôt pour quelque chose comme kdm vu que redémarrer X restaurait l'espace disque. Mais on le saura jamais, vu que j'ai mis pas mal de trucs à jour entre temps et que ça fait une semaine que le problème a disparu.
          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 à ceux qui les ont postés. Nous n'en sommes pas responsables.