Mysql restart ne fonctionne pas

Bon un petit article sur un cas bien particulier et pas simple à résoudre.

Le contexte vous avez un serveur avec des crons, on va dire beaucoup de crons ou des crons exécutés souvent ainsi qu’une partition racine / assez petite par exemple 10Go, et bien au bout d’un moment cette partition se remplie de manière importante soit dû à un remplissage de votre dossier /tmp comme vu dans un article précédent où nous expliquons comment déplacer le /tmp, soit dû au fonctionnement du service cron comme vu dans un autre article sur le remplissage de /var/mail/utilisateur.

La rencontre du problème :

Et un beau matin, vous n’arrivez plus à vous connecter sur votre PhpMyAdmin ou encore vos applications web sont toutes en rades avec des erreurs comme « Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock' ».

La solution en mode rapide :

Du coup on monte sur le serveur en ssh en root et un df -lh plus tard on s’aperçoit que la partition est pleine, ce qui explique le souci, il ne reste donc plus qu’à utiliser l’un des 2 articles cités ci-dessus pour répondre au problème (en priorité celui sur les mails moins compliqués et plus rapide pour récupérer de la place). Fin… ou pas.

Comment ça s’est passé pour nous ? :

Oui mais forcément si j’écris cet article c’est bien que ce n’est pas ce que nous avons fait. Non en tant que développeur nous on aime bien comprendre les choses et lire des logs avec des messages d’erreurs ça aide souvent à comprendre les choses. Donc on monte sur le serveur en ssh en root et on va faire un tour dans /var/log, on regarde un peu ce qui concerne mysql et on voit des choses comme des .gz au détour d’une extraction on se dit que c’est l’extraction qui a généré un dossier mysql ou pour une raison abstraite l’envie nous prend de supprimer le dossier mysql.
A ce moment là mysql est toujours en rade (car nous n’avons pas encore fait de df -lh et nous ne connaissons pas encore la raison du plantage de mysql) et nous avons fait un rm -rf de /var/log/mysql/ (Oui il y a des fois on prend des risques). Ensuite on fait notre df -lh et oui dans les logs on a vu quelque chose comme « no space left » et là on s’aperçoit que c’est l’espace disque qui manque, on vide les mails dans le fichier /var/mail/utilisateur et on se dit que dans une seconde ça sera ok donc on fait un /etc/init.d/mysql restart et là failed, on insiste et on redémarre la VM et là mysql failed encore.
Impossible on a fait de la place etc. On va voir les logs ? Bonne idée. C’est où déjà ? Dans le dossier /var/log/mysql/. Non tu te trompes ça n’existe pas ce dossier (et oui on a une mémoire de poisson rouge parfois). Et s’en suit une longue recherche sur notre ami Google.
On tombe sur un article de stack overflow. On tente le mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --socket=/var/run/mysqld/mysqld.sock et devinez quoi ça fonctionne mysql ce relance, on est tout content, on fait même un /etc/init.d/mysql restart et encore une fois c’est ok parfait.

Oui mais … :

Oui mais voilà on est au courant que nous n’avons pas relancer mysql dans les règles de l’art et pire que ça on sait qu’on prochain redémarrage de la VM, mysql n’arrivera pas à se lancer donc on veut comprendre. Et comme la loi de Murphy nous l’apprend et bien la vm a redémarré le lendemain pour une raison quelconque sur laquelle nous n’avions pas la main et forcément re-belotte mysql en rade. Il faut qu’on trouve pourquoi et après de longues recherches aussi stupide et intrépide que possible la réponse était simplement dans le fichier de conf qui précise le répertoire des logs d’erreurs mysql et oui dans le fichier /etc/mysql/my.cnf il y a une ligne qui loggue les erreurs : log_error = /var/log/mysql/error.log et ce fichier my.cnf n’est pas appelé lorsque l’on lance la commande mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --socket=/var/run/mysqld/mysqld.sock, c’est pourquoi elle fonctionne alors que la commande /etc/init.d/mysql restart utilise notre fameux fichier my.cnf c’est pourquoi elle ne fonctionnait pas à cause de la non existence du dossier /var/log/mysql/. Vous vous doutez bien que derrière on fait en root un mkdir /var/log/mysql puis on kill le process précédemment lancé en récupérant le process id via ps aux | grep mysql puis kill -9 ProcessID et enfin un /etc/init.d/mysql restart et là bonheur tout refonctionne comme au bon vieux temps.

Enjoy 😉

Source : http://serverfault.com/questions/782725/cant-start-mysql-service

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.