Aborted connection Mariadb - Debian bookworm

Merci de ta réponse. J'ai suivi ta procédure et j'ai trouvé le coupable : monit !
Bon, par contre, il me reste à trouver le moyen de corriger l'erreur, car pour l'instant à part la solution

 
log_warnings = 1

y pas d'autres pistes...
https://wpbeaches.com/set-monit-to-monitor-mariadb-on-a-cloudpanel-instance-on-ubuntu-22-04/ 

Merci mamiemando !

Bonjour,

L'erreur semble due à une application cliente qui se connecte à ton serveur de base de donnée sans s'authentifier. Dans ton rapport de log, la seule chose qu'on voit c'est que cette application cliente tourne sur la même machine que ton serveur MariaDB. Hélas, sans plus d'information difficile d'en dire plus.

Ton problème semble le même que celui évoqué dans cette discussion. Peut-être que ça te donnera des idées.

Comme le processus n'est pas authentifié, je crains que la commande SHOW PROCESSLIST ne soit d'aucune aide.

Peut-être quand lançant un minimum de services au démarrage de te machine, en les lançant progressivement tout en surveillant les logs avec une commande du genre :

tail -f /var/log/mysql/*

... tu pourrais arriver à trouver quel processus est mis en cause.

Bonne chance

Bonjour,

Cette discussion indique que ton problème est dû à une implémentation laxiste du test fait par monit pour vérifier si le serveur de base de données est en vie. En effet, monit se contente d'initier une connexion, sans s'authentifier, et vérifie que la socket est ouverte. Mais comme c'est suffisant pour conclure, monit ne poursuit pas et abandonne sans s'authentifier (d'où les messages d'avertissement au niveau de mariadb).

        /* Monitor MySQL Server */
        $data['mysqlserver'] = -1; // unknown - not needed
        if ($services['db_server'] == 1) {
           if ($this->_checkTcp($conf['db_host'], $conf['db_port']) {
                $data['mysqlserver'] = 1;
            } else {
                $data['mysqlserver'] = 0;
                $state = 'error'; // because service is down
            }
        }

L'auteur du message propose donc de faire une authentification complète. Cela oblige en contrepartie à configurer un login / mot de passe adéquat dans monit (chose qui n'était pas nécessaire auparavant), de sorte à ce que mariadb ne se plaigne plus.

        /* Monitor MySQL Server */
        $data['mysqlserver'] = -1; // unknown - not needed
        if ($services['db_server'] == 1) {
            // hail MySQL server:
            mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
            $ispcDB = mysqli_connect($conf['db_host'], $conf['db_user'], $conf['db_password'], $conf['db_database'], $conf['db_port']);
            if ($ispcDB !== false) {
                $data['mysqlserver'] = 1;
            } else {
                $data['mysqlserver'] = 0;
                $state = 'error'; // because service is down
            }
            mysqli_close($ispcDB);  // we can ignore the result (gwyneth 20220605)
        }

Je ne connais pas monit, mais je présume que $conf est peuplée à partir du fichier de configuration de monit (voir /etc/monit/monitrc) mais pour ça il faudrait regarder le code ou le fichier de configuration plus en détail.

Comme le problème a été identifié en 2022 il est assez étonnant que ce patch n'ait pas été intégré dans l'intervalle. En creusant un peu sur le dépôt de monit, je n'ai pas vu le fichier mis en cause. Apparemment il serait plutôt apporté par Ispconfig3, et si c'est bien le cas, c'est donc plutôt ce projet qui est mis en cause. Note que le fichier en question implémente la correction que je viens d'évoquer.

Bonne chance