Erreurs 500 et Mysql récurrentes

Bonjour,

J’ai un soucis depuis quelque temps avec des erreurs 500 sur Jeedom et des erreurs SQLSTATE[HY000] [2002] No such file or directory. J’ai pu voir que c’est un soucis de avec le serveur mysql qui s’arrête, avec une erreur :

systemd[1]: mysql.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
systemd[1]: mysql.service: Failed with result 'exit-code'.
systemd[1]: mysql.service: Scheduled restart job, restart counter is at 171.

puis redémarre :

-- Le redémarrage automatique de l'unité (unit) mysql.service a été planifié, en
-- raison de sa configuration avec le paramètre Restart=.

Le gros probleme est que cela arrive très très souvent, entre 5 et 10 minutes environ. On peut le voir dans le syslog.

Après analyse, en désactivant tous les plugin de jeedom pour trouver la cause, il s’avère que cela vient du plugin Zwave et/ou du plugin téléinfo.

Quand ces plugins sont désactivé, je n’ai aucun soucis, mysql ne s’arrête jamais. Quand j’active zwave, tout fonctionne correctement pendant un temps, si je fait un top j’ai ca :


    PID UTIL.     PR  NI    VIRT    RES    SHR S  %CPU  %MEM    TEMPS+ COM.
1779262 www-data  20   0  903160  48860  12036 S   3,0   0,8  21:43.82 python
2784633 www-data  20   0  241244  35012  24760 S   2,0   0,6   0:05.92 apache2
1756112 www-data  20   0  426636  53368  10716 S   1,0   0,9   9:57.16 python3
2845299 mysql     20   0 2857240 475660  35452 S   0,7   7,8   0:03.05 mysqld
1751573 root      20   0  396032  44904  32916 S   0,3   0,7   5:20.67 deCONZ
2824979 www-data  20   0  241148  34704  24384 S   0,3   0,6   0:02.87 apache2
2834142 lamorad+  20   0   14880   4480   3652 R   0,3   0,1   0:03.82 top

Au bout de quelques minutes, mysql occupe 100% du CPU :

    PID UTIL.     PR  NI    VIRT    RES    SHR S  %CPU  %MEM    TEMPS+ COM.
2838769 mysql     20   0 3057304 547852  35976 S 100,7   9,0   0:18.73 mysqld
2556726 www-data  20   0  243016  38724  26976 S   2,6   0,6   0:18.08 apache2
1779262 www-data  20   0  903160  48860  12036 S   2,0   0,8  21:42.19 python
1756112 www-data  20   0  426636  53352  10716 S   1,3   0,9   9:56.47 python3
1751573 root      20   0  396032  44904  32916 S   0,7   0,7   5:20.30 deCONZ
2834142 lamorad+  20   0   14880   4480   3652 R   0,7   0,1   0:03.41 top
     10 root      20   0       0      0      0 I   0,3   0,0   4:15.31 rcu_sched

Et c’est a ce moment la que mysql s’arrete avec le code erreur ci-dessus.

Si je regarde le log du plug in zwave, voici un extrait :

[2021-10-21 09:52:21][ERROR] : Error on send request to jeedom, return code 500
[2021-10-21 09:57:13][ERROR] : Error on send request to jeedom, return code 500
[2021-10-21 10:02:10][ERROR] : Error on send request to jeedom, return code 500
[2021-10-21 10:07:01][ERROR] : Error on send request to jeedom, return code 500
[2021-10-21 10:16:51][ERROR] : Error on send request to jeedom, return code 500
[2021-10-21 10:26:52][ERROR] : Error on send request to jeedom, return code 500
[2021-10-21 10:36:40][ERROR] : Error on send request to jeedom, return code 500
[2021-10-21 10:51:13][ERROR] : Error on send request to jeedom, return code 500
[2021-10-21 10:56:07][ERROR] : Error on send request to jeedom, return code 500
[2021-10-21 11:01:03][ERROR] : Error on send request to jeedom, return code 500
[2021-10-21 11:05:57][ERROR] : Error on send request to jeedom, return code 500
[2021-10-21 11:10:51][ERROR] : Error on send request to jeedom, return code 500
[2021-10-21 11:20:40][ERROR] : Error on send request to jeedom, return code 500

En faisant des recherches sur ce forum community, je vois que bcp de gens on posté des log de ce plugin avec ce genre d’erreur 500.
Par exemple ici : Desactivation des modules zwave

Avec le plugin téléinfo c’est encore pire ! Mysql utilise rapidement plus de 100% du CPU et plante avec la même erreur. De plus j’ai un compteur en trop qui à été créé par le plugin, et je ne peux pas le supprimer car cela plante immédiatement mysql et provoque une erreur 500. (J’ai également vu certains sujet ici même avec ce même probleme de suppression)

J’ai testé quelques trucs, comme démarrer le serveur avec la commande innodb_force_recovery = 1 dans le /etc/mysql/my.cnf

La, le serveur reste correctement en ligne, mais les services ne fonctionnent plus de manière 100% opérationnelle, par exemple on peut plus créer un équipement, et certains scenario ne fonctionnent plus.

Dans la doc ils indiquent que démarrer avec le paramètre à innodb_force_recovery à 1 force mysql à ignorer les corruptions.

J’ai donc fait un mysqlcheck de toutes mes bases, et le résultat est ok sur toutes les tables de toutes les bases, du coup je sèche la…

J’ai fait un fsck de la partition et aucun pb n’a été détecté.

Est ce que vous avez une idée ?

Je suis avec Mysql 8.

Merci pour votre aide.

Bonjour,

à mon avis tu a 2 problèmes: 1 sur le plugin z-wave et 1 sur le plugin télé-info… Du coup je te conseille plutôt de faire 2 topics, dans la section plugin et ajoute un peu plus d’infos genre les logs en mode debug + 1 arrêt / relance du démon - pour z-wave en tout cas, je ne sais pas si télé-info a aussi un démon + la page santé ? Et la version jeedom utilisée + le matériel ?
Pour le plugin télé-info à priori le dev peut intervenir pour le corriger. Pour le z-wave c’est pas gagné, peut être que tu devrais tenter de désactiver certains modules :confused:

Bonjour,
En complément, ce qu’on peut déjà dire c’est que le log donné ici ne montre pas le problème mais la conséquence.
C’est parce que jeedom a un problème (apparemment avec la db) que zwave plante et pas l’inverse.

Bonjour,

oui effectivement, mais c’était pour illustrer que les actions de ces plugin ont la même conséquence : le crash de Mysql.

Pour répondre aux questions :
-le téléinfo à également un daemon
-la page santée est pas tellement fonctionnelle sur ce plugin
-Le développeur a malheureusement abandonné le plugin m, et ne répond plus, ni ici, ni sur son github.

J’utilise la Jeedom 4.1.27 sur un miniPC type NUC.

En fait zwave ne plante pas, c’est le serveur SQL qui plante quand on active le plugin zwave.

La db a probablement un soucis, comme je l’indique dans mon message le fait que le serveur soit ok avec le paramètre innodb_force_recovery à 1 le prouve.

Ce qui est bizzare c’est que les mysqlcheck indiquent que tout est ok.

Je vais continuer a investiguer.

Hello,

Je pense avoir trouvé le probleme.

Mon systeme de backup s’est mis lui aussi a sortir des erreurs:

Unable to exec first piped command /usr/bin/nice -n 10 /usr/bin/mysqldump --defaults-extra-file=/root/.backup-manager_my.cnf --opt -uBACKUP -hlocalhost -P3306  jeedom; check /tmp/bm-command.q6a2v3

Et effectivement en faisant un dump manuellement, j’ai une erreur systématique au meme endroit :

~$ sudo mysqldump --all-databases  > backupDB.sql
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `history` at row: 659812

Je constate un redémarrage de mysql au même moment ou il tombe sur cette ligne.

J’ai donc vidé la table avec un Truncate et c’est repartit.

Il y avait donc bien une corruption je pense, très bizzare que le mysqlcheck ne la voyait pas !

Quelque jours après cette manip, je remarque que le serveur SQL plante encore de temps en temps, avec la même erreur que précédemment. Mais c’est de l’ordre de 1 fois par jour ou tous les 2 jours.

Pour moi ça commence à sentir un problème de disque et si j’étais à ta place j’envisagerai de le changer. Si ça se trouve les secteurs défectueux sont vers la partie de la bdd qui gère le backup mais ça pourrait s’étendre.

Oui en effet. Cela pourrait être une piste.
J’ai fait un fsck et rien de special, les données smart n’indiquent rien d’alarmant.
Ces disques sont en Raid 1 et j’ai un backup journalier, donc la perte de données est réduite en cas de défaillance.

Mais une corruption sur une donnée d’une table n’indique pas forcément un disque dur HS.

Ah ça va en effet tu es plutôt bien armé alors ! Bon courage.