Point de montage qui se remplit...

[Bacteries]

Bonjour,
j'ai un soucis avec mon serveur depuis quelques jours.

Sur mon site certaines pages se sont mises à mal s'afficher, après petite enquête ça vient de MySQL qui sort une erreur de manque de place.
J'ai donc été faire un df-h qui me donne ça :

Filesystem            Size  Used Avail Use% Mounted on
/dev/md2              7.3G  7.0G  7.8M 100% /
tmpfs                 376M     0  376M   0% /dev/shm
/dev/md1               38M  8.4M   28M  24% /boot
/dev/md5               22G  7.9G   13G  39% /home
/dev/md6              7.3G  240M  6.7G   4% /var

J'ai donc un soucis avec /dev/md2.
J'ai été voir dans /var/log (je suis sous Debian) et rien de spécial, j'ai supprimé qqes logs (pour 60Mo) et c'est reparti.

J'ai lancé des commandes pour savoir qui me prenait de la place mais je vois rien d'anormal
du -ak | sort -nr | head -100
du /var/log -akhx | sort -nr |less

Mais la taille de mon /dev/md2 continue de grossir, sans que je sache où et comment. Ca va pas super vite, 0.1Mo toute les 5 minutes peut être, mais au final ça me re-remplit le disque et je ne sais pas d'où ça vient.
Les mails reçus allant dans /home ça ne joue pas, le site étant aussi dans /home idem, les logs étant dans /var je me dis que ça pourrait être ça mais y'a pas de dossier grossissant vite là dedans.

Des pistes? (et oui : mon niveau d'admin linux est fortement limité)
Merci.

 

[jcaron]

Qu'est-ce-qu'il y a dans / qui ne soit pas monté ou un symlink vers un autre endroit? Il n'y a pas un /tmp, un /log? Il y a certainement un /usr avec possiblement des choses pas sympa au deuxième niveau. Ce n'est pas dans /var/log puisque /var est dans un fs séparé. Tu as bien executé ton du après un cd / ?

Si MySQL se plaint c'est qu'il stocke quelque chose là-dedans, probablement son historique.

Pistes:
cd /
du -skx *

ça va te donner la taille de chaque dir à la racine. Elimine ceux qui sont "montés" (/home, /var, /boot), prends le plus gros, fais un cd dedans, et recommence du -skx * (ou du -skx * | sort -rn). Comme ça tu vas pouvoir descendre progressivement vers les gros fichiers.

locate mysqld-bin ou locate 000001

ça devrait te dire où sont les fichiers mysql. S'il y a un .index qui grossit sans fin, c'est que les logs binaires de réplication sont sauvegardés même si tu ne t'en sers pas. Il y a une commande mysql pour purger ça (purge binary logs), et une option de la config de mysql pour qu'il arrête de les stocker.

NB: je n'ai l'habitude ni de Debian ni de Mysql (je suis plutôt FreeBSD et Postgresql), donc je tape un peu au hasard...

Jacques.

 

[Bacteries]

Merci pour la réponse, mais je ne trouve toujours pas :

10305368        home
364024  usr
120324  var
13824   lib
4676    sbin
4492    etc
4447    boot
3723    proc
2812    bin
140     root
100     dev
64      tmp
16      lost+found
4       srv
4       opt
4       mnt
4       media
4       initrd
0       vmlinuz.old
0       vmlinuz
0       sys

Dans /usr/ j'ai tout ce qui est doc, traductions, ... J'en ais déjà supprimé pour parer au plus pressés, mais ça ne résoud pas mon problème. Idem dans lib je vois rien qui bouge.

J'ai testé en supprimant quelques fichiers inutiles, en regardant la taille avant, après, puis après quelques minutes.
Il semblerait que ça vienne de /proc.
J'ai redémarré, et hop 6Go de gagné...

Des idées de la provenance de ce problème?

 

[jcaron]

Si tu supprimes un fichier qui est encore "ouvert" (auquel un programme est en train d'accéder) il n'est réellement supprimé que lorsque le programme en question arrête de l'utiliser (et pendant ce temps-là il peut continuer à écrire dedans). C'est pour ça que les fichiers de logs par exemple, il ne faut pas les supprimer (sauf s'il s'agit d'un vieux fichier après rotation), mais les tronquer (>nomdufichier en sh/bash, :>nomdufichier en csh/tcsh).

L'autre option c'est de relancer le programme qui l'utilise après suppression (ce qui est implicitement ce que tu as fais en redémarrant).

Jacques.