En fait je suis entrain de faire face à un grave problème
Tout à commencé quand j’ai voulu tester CakePHP, je me suis dit, plutôt que d’installer EasyPHP sur mon pc, je vais me servir d’un apache qui traine chez moi et qui supporte le PHP.

Premier test, http://rhea, j’arrive sur une page me disant It Worked! If you can see this page, then the people who own this host have just activated the Apache Web server software included with their OpenBSD System. They now have to add content to this directory and replace this placeholder page, or else point the server at their real content.. Pas mal, je tombe sur un pc qui a planté (une chance sur deux en fait, yen a un qui a planté le mois dernier et j’ai pas encore regardé ce que c’était)

je me log en ssh voir si je trouve pas un dossier avec une page .php.
Miracle ! m’écriais-je un dossier /var/www/htdocs contient un dossier Cacti.

Premier reflexe, ftp pour envoyer les fichiers de CakePHP je me connecte en user, j’upload le tout, mais je remarque du coin de l’oeil sur mon PuTTY que j’ai ces messages qui s’affichent depuis deja quelques bons mois (…… bon d’accord mais pas plus d’un an ou deux)
Jan 17 21:00:04 Rhea /bsd: uid 521 on /var: out of inodes
Jan 17 21:00:04 Rhea /bsd: uid 521 on /var: out of inodes

Bref je fais ma petite affaire, je commence nonchalament a uploader les fichier dans le home directory.
Jusque là tout va bien.
C’est alors que, connecté en root dans PuTTY je cherche à déplacer le dossier cake_1.1.12.4205 dans /var/www/htdocs/.
Pareil, jusque là, rien de transcendant … mais … c’est le drame:
_**{23:48:01}[root@Rhea] ~ $ mv /home/eskimo/cake_1.1.12.4205/ /var/www/htdocs/

/var: create/symlink failed, no inodes free
Jan 17 23:48:17 Rhea /bsd: uid 0 on /var: out of inodes
mv: /var/www/htdocs/cake_1.1.12.4205/: No space left on device
mv: /bin/cp: terminated with 1 (non-zero) status: No such file or directory
**_

Donc là visiblement ça se corse. Petite vérification de l’espace disque:
**{23:50:42}[root@Rhea] ~ $ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/wd0a 1.2G 477M 670M 42% /
/dev/wd1a 4.0G 2.4G 1.3G 65% /usr
/dev/wd2a 7.8G 3.4G 4.0G 46% /var
**

Bon … un petit google, pour finalement tomber sur ce post, ce qui me permet de découvrir l’option "-i" de la commande df (df -h -i), qui donne ce résultat:
**{23:50:43}[root@Rhea] ~ $ df -h -i
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/wd0a 1.2G 477M 670M 42% 3934 160928 2% /
/dev/wd1a 4.0G 2.4G 1.3G 65% 32554 497876 6% /usr
/dev/wd2a 7.8G 3.4G 4.0G 46% 1030398 0 100% /var
**

Il faut comprendre que chaque fichier crée comporte un inode, qui est en quelques sortes sa place sur le disque dur. Quand ces inodes ne sont plus disponibles, le système ne peut plus créer de fichier, même s’il reste de la place sur le disque dur.
La seule solution est de faire le menage.
Grâce à cette commande: du /var -d 1 -h|sort -n -r > sort_var on va pouvoir visualiser (stocké dans le fichier “sort_var”), classés par ordre croissant les differents dossiers ainsi que la place qu’ils utilisent, et donc le nombre d’inodes associé.
Voici le résultat: **7069216 /var
5644048 /var/mysql
1351604 /var/spool
1351460 /var/spool/exim
1213992 /var/spool/exim/input
94464 /var/spool/exim/msglog
42852 /var/spool/exim/logs
34384 /var/log
**

MySQL semble le plus gourmant.
Il s’avère qu’il y a 958532 fichiers dans ce dossier (merci à ls | wc que je ne connaissais pas non plus).
Donc le fin mot de l’histoire c’est que j’ai plein (dans les 900 000 que ca m’etonnerait pas, mais je sais pas ce qu’il y a dedans, ni à quoi ils servent. Faut dire c’est d’un explicite “Rhea-bin.145468”, meme si apres **{00:32:28}[root@Rhea] /var/mysql $ file Rhea-bin.145469
Rhea-bin.145469: MySQL replication log
**

ça parle un peu plus.

Apparement il existe une commande mysql purge_replication_log qui ferait le boulot. Mon soucis c’est que le serveur mysql ne peut pas accepter de connexion car il a dû planter depuis longtemps maintenant avec ce problème d’inodes.
Il faut purger un autre dossier … pourquoi pas dans /var/spool/exim/ :)
Encore mieux, dans le dossier input qui concerve tous les mails, et il y en a 46576 (et il y en a qui date du 2 juin 2005, à plusieurs mails par jour), donc zou tout ca pfiouuuuuuuuuuu…….

Ce qui nous amenne à encore une autre découverte, la commande rm ne supporte pas des listes de fichiers à effacer trop longue:
**{00:52:07}[root@Rhea] /var/spool/exim/input $ rm -rf *
-bash: /bin/rm: Argument list too long **

Un petit retour quelques jours en arrière, pour réutiliser ceci:
for i in ls; do rm $i;done

Et nous y voilà, **real 11m0.182s
user 0m19.968s
sys 3m22.483s
**

plus tard avec 46572 inodes de libres (95% utilisés) qui vont permettre de se connecter à MySQL et tenter une purge des réplications de logs.

En attendant que tout ceci se finisse, j’ai modifié la crontab pour que j’arrete de recevoir des mails qui ne me servent pas à grand chose.

Une fois ceci fait, je pense avoir trouvé la solution à mon problème. Evidement ce qui arrive ici n’est qu’un manque de configuration, la preuve en est dans le fichier /etc/my.cnf _**# Replication Master Server (default)

binary logging is required for replication

log-bin **_

Une option donc qui permet à un serveur maître et un serveur esclave de répliquer les données. A ce détail près que ce n’est pas quelque chose de désiré.
Il va donc je pense, être temps de faire du ménage aussi par ici. J’ai tout de même l’avantage de n’avoir aucune données sensible sur cette base, qui ne m’a que très peu servi (en plus). Donc on va pas se faire suer, je vais tout effacer, quitte à ce que ca ne marche plus.

Solution de facilité je sais, mais pour une fois que je peux faire le sagouin autant en profiter :)
Et vu que de toute facon le mysql redemarre a peu pres toutes les 60 secondes (ça je ne me l’explique pas), je ne peux pas me connecter pour voir la liste des bases à dumper.
la solution qu’il me reste pour le moment c’est de conserver les données en faisant un tar du dossier mysql pour voir après ce que ca donne si on efface tout.

Ya plus qu’à attendre que ca se finisse …..(il s’est déjà passé 24h depuis le debut du billet)

D’après ce que je peux en voir pour le moment, à priori si je n’efface que les fichiers Rhea-bin.* je devrais pouvoir conserver mes données, dont les bases sont sotckées dans des dossiers.

Bref pour finir, un petit coup de la boucle for pour effacer les fichiers et conserver les dossier et le tour est joué.
Il ne reste plus qu’a surveiller mais tout devrait bien se passer … que d’histoires que d’histoires, et au final je testerais cakephp plus tard ;)