Forum Linux.debian/ubuntu Mon disque dur se rempli tout seul

Posté par Mammnon le 19 décembre 2007 à 00:04.

Étiquettes :

déc.

2007

Bonjour à tous.

Mon problème? Tout est dans le titre.

Bon apres quelques heures de recherche je viens vers vous pour chercher d'autre piste à explorer.
En gros j'ai un partition de 45Go que je monte sur /home . L'autre jour un petit df me donne 100%. Comme je suis du genre à faire le menage rarement je panique pas et je degage 20Go de film. Pas de problème jusqu'ici. J'ai vu rouge quand pour une autre raison je regarde de nouveau un petit df 2h plus tard pour voir que j'étais encore à 100%!!! Alors là je suppr 10Go de plus et je 'df' toute les 2secondes. Et je vois l'espace retrecir à vus d'oeil, d'environ 2Mo/s !!!

Bon voilà j'espere avoir été clair sur le problème.

Au niveau des pistes recherchés, j'ai verifié qu'apres reboot je ne recuperais pas mon espace, que mon swap ne soit pas l'origine du problème, la cron est completement vide (enfin mnt), et j'ai verifié que les processus lancé au demarrage de mon ordi soit connu du monde normal. J'ai aussi verifié avec smartctl que mon DD ne soit pas mort (ce qui aurait étonnant que seul une partition soit touché)

Pour répondre enfin aux autres questions: "Non je ne sais pas depuis quand ca dure".

Linux Debian 2.6.19.2 (compile perso du kernel)

Merci beaucoup de votre aide!!! (mon X en root en attendant c'est pas serieux...)

++

# une petite info en plus

Posté par Mammnon le 19 décembre 2007 à 00:07. Évalué à 1.

J'ai oublié de préciser que lorque je verifie la taille des fichiers présent sur mon /home je suis à environ 10Go maintenant et df m'indique toujours 100% et la moindre ecriture retourne l'erreur disque plein...
- [^] # Re: une petite info en plus
  
  Posté par peck (site web personnel) le 19 décembre 2007 à 11:56. Évalué à 1.
  
  Dans ce cas c'est qu'un processus continue d'écrire dans un fichier qui a été supprimé. C'est possible parce que sous linux c'est le file descriptor qui compte et pas le nom du fichier.
  
  Pour détecter les fichiers dans cette situation :
  
  $ lsof | grep delete
  
  Ainsi tu auras le fichier et le processus en cause. Il suffit de tuer le processus pour que le ficheir disparaisse définitivement.
# df et du

Posté par NeoX le 19 décembre 2007 à 01:09. Évalué à 1.

df donne l'espace libre

du donne l'occupation.

du -h --max-depth
te donnera la taille de chaque dossier qui se trouve dans le dossier courant.
ca peut aider pour trouver le truc qui prend de la place.

faut peue-tre aussi arreter de muler ou de logger tout ce qui se passe.

l'integralité du df -h pourrait nous permettre de savoir si c'est vraiment /home qui se remplit
- [^] # Re: df et du
  
  Posté par Mammnon le 19 décembre 2007 à 02:21. Évalué à 1.
  
  bonsoir ,
  
  comme je l'ai dit l'espace occupé (le 'du -h --max-depth=1' ) me donne environ 10Go sur /home...
  La question reste donc en suspend: mais où sont donc passé les 35 autres Go ?
  
  Concernant les mules et de manière plus générales tous les serveurs ont été coupés. Enfin mes logs sont dans /var/logs (par defaults) et /var/mesLogs (pour les perso).
  Enfin aucun processus n'appartenant aux user qui ont leurs home dans le fameux dossier n'est lancé....
  - [^] # Re: df et du
    
    Posté par Obsidian le 19 décembre 2007 à 03:18. Évalué à 2.
    
    J'ai déjà eu ce genre de problème avec un log qui se remplissait à cause d'une boucle sans fin.
    
    Si c'est bien /home qui se remplit, vérifie toutefois s'il n'y a pas de liens symboliques qui s'y réfèrent depuis autre part (/var/log, /tmp), etc.
    
    D'autre part, il est possible que ton espace soit complètement alloué si un programme crée une multitude de fichiers qui allouent chacun 4 kilo-octets. En principe, du n'est pas dupe, mais ça dépend des options qui lui sont passées par défaut.
    
    Un core dump à répétition est aussi envisageable.
    
    Sais-tu quel répertoire de /home est le plus volumineux ? As-tu exploré le contenu de lost+found ?
    
    Enfin, un top au moment où le phénomène se produit ainsi qu'un lsof | grep home devrait t'aider à localiser le processus fautif.
    
    Bon courage.
    - [^] # Re: df et du
      
      Posté par Gyro Gearllose le 19 décembre 2007 à 09:30. Évalué à 2.
      
      Hello !
      Je peux donner une piste, qui vaut ce qu'elle vaut, en accord avec ce que j'ai pu constater sur mon propre système :
      Les programmes de KDE (et ce doit être vrai pour d'autres environnements graphiques) sont très verbeux et causent sans cesse dans ~/.xsession-errors. Donc, il faudrait peut-être commencer par ce fichier.
      Soit en faisant un ls -lah .xsession-errors dans la home dir, soit en faisant un tail -f .xsession-errors.
      Au moment où je frappe ces quelques lignes, je constate que celui qui est présent sur ma machine, dans ma home dir fait quand même pas loin des 22Mo, et qu'il se remplit au fur et à mesure de la frappe de ce message (appels successifs à KDict à chaque fois que j'ai fini de frapper un mot).
      
      En passant, si quelqu'un sait ici comment rendre les programmes de KDE moins verbeux, et de ne remonter dans ce fichier que les erreurs (d'après le nom, il ne devrait y avoir que ça), je suis preneur.
      Voilà, en espérant que cette piste se montrera pertinente, et que quelqu'un aura une idée pour résoudre ce bavardage des applis KDE.
# teste :

Posté par SLMitch le 19 décembre 2007 à 09:25. Évalué à 1.

Si j'ai bien compris :
df -h /home/
Te donne apparemment 100 % utilisé, soit 45 Go.
un : du -sh /home/ te donne 10 Go d'utiliser

Plusieurs solutions pour que cela fasse ca :
* J'ai déjà vu le bug sur du vieux raid megaraid : seule solution = reboot
* Tu as supprimer un fichier qui devient enorme, mais le descripteur de fichier n'est toujours pas libéré. Donc aucune place n'est encore gagné.

Fait un : lsof |grep deleted
tu veras tous les descripteurs qui sont "en l'air"
Mais je pense que c'est bien ca.

Sur la dernière ubuntu, j'ai aussi vu les fichiers de cache de trackerd il me semble prendre 30Go TRES vite, mais le du -sh /home te les montrerai si c'était ca.

Si tu veux un truc "graphique" pour voir ce qui prend de la place, moi j'utilise filelight .
# RESOLUS! Merci à tous

Posté par Mammnon le 19 décembre 2007 à 20:09. Évalué à 1.

Bonsoir,

alors la bonne réponse a été donné par SLMitch et peck, mais en plus vicieux. Je m'explique: j'ai un processus perso rattaché à init qui se fork tant que le CPU<70% et les fils se ferme en accord afin de libéré du proc afin qu'il ne dépasse jamais 80%. Ces processus lisent sans fin des fichiers pour retrouver des redondances et réduire la taille des fichiers. (Bon c'est tiré par les cheveux mais on est geek ou on l'es pas...).
Le hic: La compression était terminé est chaque fils tournait sans fin( erreur de récursivité connu...). Apparemment bien que je supprimait les fichiers et killer les processus, le descripteur restait ouvert. J'ai pas bien compris pourquoi ca augmentait la taille de disque utilisé mais bon...

Apres quelques test j'ai reussi a simuler la meme erreur en lisant un film avec gmplayer (qui chez moi est vérolé) et un kill -9 intempestif sur mplayer... J'ai beau par la suite supprimer le film lu ca change rien, gmplayer reste en zombi et la taille re-augmente.

C'est quand même bizarre que ce genre d'erreur (lire en boucle un fichier supprimé) fasse augmenter l'espace occupé... Une idée du POURQUOI?

Bon, quoi qu'il en soit merci à tous pour votre aide!
++

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.