Dans les versions 3.1.2, 3.1.3, 3.1.4 et 3.1.5, Ispconfig peut rencontrer un dysfonctionnement lorsque le serveur SGBD est indisponible. Cela peut par exemple se produire au démarrage du serveur si les services d'Ispconfig démarrent avant le serveur MySQL.
(À noter que ce problème survient notamment lors de la mise à jour de Ispconfig.)
Lorsque ce problème se produit, cela peut provoquer une énorme quantité de messages d'erreur récursifs qui vont avoir pour conséquence de remplir le fichier /var/log/ispconfig/cron.log.
Ce fichier log peut alors atteindre un poids de plusieurs gigas en quelques dizaines de minutes. Ayant pour conséquence de ralentir la lecture et l'écriture de ce même fichier par Ispconfig. La charge système devient alors anormale et cela risque de mener à une indisponibilité totale du serveur dans les 24h (souvent au moment du backup automatique nocturne). Il faudra alors procéder à un redémarrage à froid.
Voici le style de messages d'erreur qui sont renvoyés lorsque cela se produit :
On peut voir que la dernière ligne fait mention d'une tentative d'écriture dans la table sys_log de la base de données d'Ispconfig. (wtf ??!!)
Revoyons la scène au ralenti :
- Le serveur MySQL est indisponible (ou en cours de démarrage).
- Le cron d'Ispconfig insert un message dans le fichier journal /var/log/ispconfig/cron.log pour signaler que le SGBD est indisponible.
- Ispconfig tente d'insérer un enregistrement dans la table sys_log du SGBD (indisponible !) afin de journaliser l'échec d'accés au serveur de base de données... et ainsi de suite..
- Le serveur ralentit jusqu'au moment où il finit par crasher.
Pour résoudre ce problème, rendez-vous aux alentours de la ligne 230 du fichier server/lib/classes/db_mysql.inc.php présent dans le dossier Ispconfig et corriger la portion de code de la manière suivante :