Hier encore, abricocotier était down. PLus exactement, le serveur est tombé vers 12h29 et est remonté vers 12h59 (d’après les dates données par Mon.itor.us, mais en fait il a été down un peu moins de temps). Déjà le matin, en publiant un billet sur le Windows Phone 7, j’avais eu la désagréable surprise de ne pas pouvoir uploader mes images correctement. Je me disais que c’était peut-être parce qu’après la tombée du serveur la veille, PHP n’avait peut-être pas été redémarré dans les même conditions que précédemment, et les fonctions de PHP permettant de recevoir les fichiers et de les redimensionner n’étaient peut-être pas utilisables. En fait, pas du tout.    

Il se trouve simplement que j’étais arrivé à la limite haute de la capacité de mémoire sur la partition où est stocké mon blog sur le serveur où il est, partition qui contient également les logs Nginx/Apache du serveur. Oui, je sais, c’est pas bien. Mais c’est le genre de détail qui est peu important avant qu’on ne se prenne le mur, d’autant que j’aurais parié que les logs ne prendraient pas plus de place que de raison, grâce à logrotate que je croyais fonctionnel (logrotate s’assure que le total des logs d’un dossier reste à un certain niveau de place en mémoire).

Donc j’étais arrivé à la limite de mon disque, soit… 4,7 Go (sur cette partition, hein, en fait j’en avais une à côté qui était vide et qui faisait… 80Go). En fait je ne savais pas du tout que les dossiers accessibles à la racine étaient chacun dans une partition compartimentée, donc je croyais bénéficier d’une taille de stockage totale/cumulée de 100Go, comme le prévoyais l’offre de serveur à laquelle j’ai souscrite.

Au passage, pour connaitre la répartition du stockage et sa charge, voilà la commande :

df -h

Ce qui donne chez moi (après avoir réglé le problème) :

$ df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/hda1             950M  343M  559M  38% /

varrun               1000M   72K 1000M   1% /var/run

varlock              1000M     0 1000M   0% /var/lock

udev                 1000M   36K 1000M   1% /dev

devshm               1000M     0 1000M   0% /dev/shm

/dev/hda5             4.7G  1.5G  3.2G  32% /mondossier3

/dev/hda6             4.7G  1.4G  3.4G  29% /mondossier2

/dev/hda7              81G  661M   81G   1% /mondossier1

none                 1000M     0 1000M   0% /tmp

Donc, pour revenir à nos moutons, le matin, pas de possibilité d’uploader correctement mes images.

Et à midi, le site qui ne répond plus.

En confiance après le redémarrage correct de la veille, je demande un redémarrage du serveur sur l’admin de 1and1, ce qui se passe correctement, mais de ce que je constatais à ce moment là, Nginx/Apache fonctionnaient, mais sur abricocotier.Fr, il n’y avait plus de connexion MySQL. A l’inverse, il semblait que microblog.abricocotier.fr ait une connexion MySQL… Donc j’ai d’abord pensé à un hack du site (des petits malins qui auraient été s’amuser avec le install.php de WordPress), ou auraient réussi à virer le config.php…

Le soir, en ayant ENFIN accès à un PuTTy, j’ai pu constater qu’il n’en était rien, et que le site avait l’air d’être intact, en tout cas en ce qui concernait les fichiers. Par contre, MySQL m’affichait l’erreur suivante :

Warning: session_write_close() [function.session-write-close]: write failed: No space left on device (28) in /usr/share/phpmyadmin/libraries/common.lib.php on line 648

Warning: session_write_close() [function.session-write-close]: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5) in /usr/share/phpmyadmin/libraries/common.lib.php on line 648

#0  PMA_sendHeaderLocation(http://localhost/phpmyadmin/index.php?lang=fr-utf-8&convcharset=iso-8859-1&collation_connection=utf8_unicode_ci&token=ec462f0246b8932e5b46ee9417dd491f) called at [/usr/share/phpmyadmin/libraries/auth/cookie.auth.lib.php:543]
#1  PMA_auth_set_user() called at [/usr/share/phpmyadmin/libraries/common.inc.php:758]
#2  require_once(/usr/share/phpmyadmin/libraries/common.inc.php) called at [/usr/share/phpmyadmin/index.php:34]

Fatal error: PMA_sendHeaderLocation called when headers are already sent! in /usr/share/phpmyadmin/libraries/common.lib.php on line 655

Après une recherche sur le forum Ubuntu-fr, j’ai pu constater qu’il pourrait s’agir d’un problème de taille disponible sur le disque… Ce qui m’a amené à supprimer mes logs Nginx, « pour voir »… Et quand j’ai vu que je supprimais 3Go de logs, j’ai compris qu’il y avait peut-être là quelque chose de louche.

Après avoir exécuté les commandes suivantes :

cd /mondossierdelog/nginx

rm *.gz

rm *.1

(rien qu’avec ces trois commandes, j’ai gagné 3Go)

MySQL ne voulait toujours pas fonctionner… Je me suis donc dis que c’était peut-être à cause du mauvais démarrage de celui-ci, et donc j’ai demandé (pour la troisième fois) un redémarrage du serveur.

Et là… c’état la quille ! Tout à refonctionné instantanément.

Bilan :

• Mettre les dossiers de ses sites sur la plus grosse des partition
• Mettre ses logs sur la plus grosse des partition et/ou s’assurer que logrotate fonctionne correctement !