Quand on fait des betises
Par Seza le mardi 13 février 2007, 23:21 - Bug - Lien permanent
Voici ce qui peut se passer quand un serveur ne fonctionne plus. Avec mes faibles compétences en administration linux voici ce qui arrive : on fait des erreurs de jeunesse et de précipitation.
Donc ce soir 20 heures passées, déjà tard, il est temps de rentrer bien au chaud chez soit et de laisser ses bébés s'endormir tout doucement.
C'est toujours à ce moment que votre patron vient vous voir pour vous dire, dis donc je n'arrive plus à synchroniser mes emails.
- "Ah, je vais jeter un oeil".
Un premier test outlook décevant, un second test en ligne de commande sous dos, en effet erreur MySql .... ne peut pas écrire dans le PID 111.
Oui MySql, c'est un serveur administré par Plesk qui nécessite donc une base de données pour fonctionner.
Je me connecte au serveur, un petit top. J'observe directement un processus plesk prenant 75 % de CPU. Etrange je poursuis mon chemin, je vais à la recherche du fichier mysql.sock, bien présent, bien les droits d'écriture pour l'utilisateur mysql.
Pas le temps de chercher l'erreur malgré que ça soit intéressant, je redémarre MySql. Extinction du serveur : Echec, redémarrage du serveur Echec, impossible d'écrire dans le fichier mysql.log. Tiens encore plus étrange j'avais jamais vu cette erreur. je vais voir le fichier de log, il a pas les droits d'écriture et visiblement il n'a jamais écrit dedans puis qu'aucun log gziper apparait et que le fichier mysql.log fait 0 octet. Je met donc les droits d'écriture pour mysql et là une erreur que je n'avais jamais vu non plus : impossible de changer les droits pour ce fichier. Je suis pourtant root qu'est ce qui se passe ?
Dernière tentative je kill le process plesk qui semble boucler, peut etre qu'il bloque les fichiers... "ça serait peut probable mais bon..."
Une fois le process killé, je retente de mettre les droits correct : Echec cuisant. Dernière tentative de redémarrage de MySql, échec cuisant.
Il reste une dernière solution encore plus bourrinne que de redémarrer MySql, le redémarrage du serveur. Un petit : init 0 et .... merde c'était init 6 qu'il fallait faire... Echec très cuisant et j'ai vraiment l'air d'un imbécile.
Au moins le serveur ne chaufferas plus le datacenter pour rien ^^ La morale de cette histoire, ne pas se précipiter face à un problème, prendre le temps de l'analyser, ne pas être présent au bureau après 19 heures.
Bonne soirée à tous !
Commentaires
Salut, J'ai commencé a m'interresser a linux il n'y a pas trés longtemp par conséquent je trouve ton blog trés bien fait et interréssant.
Mais voici la raison pour la quelle je post.
J'ai suivi ton tutoriel pour installer Iptable, SSH, MySQL ainsi que Apache2 et ca a fonctionné plus ou moin...
Néanmoins je me demandais si l'erreur " L'administrateur système a désactivé votre compte " pouvait éventuellement venir de Iptable ou alors ssh lors de la création des utilisateurs virtuelle ?
( il y a de grande chances que je revienne souvent te posé des questions donc il serait plus simple de communiquer par mail, pour éviter de flooder ton blog :p ^^)
Salut nT,
Comme sur beaucoup de forum quand tu cherches une réponse, tu vois très souvent les gens expliquer leur problème mais aussi donner plein d'infos sur pourquoi quand comment. C'est très utile pour comprendre dans quel contexte l'erreur arrive.
C'est pourquoi je vais te demander le contexte (un petit exemple qui me montre quand l'erreur arrive) ça serait idéal.
Dans un premier temps je penserais à un compte inactiver par root. Mais ça serais un compte UNIX réel. Bon pas de perte de temps en spéculation. J'attends tes infos.
Pour me contacter par email tu peux utilisé ma page contact.
@ Bientôt