SQLSTATE[HY000] [2002] Connection refused

Bonsoir,

Je possède une Jeedom Smart V3 et tout fonctionnait sans problème. Depuis quelques jours impossible de me connecter dessus. J’ai ce message d’erreur “SQLSTATE[HY000] [2002] Connection refused”

Comment arriver à me connecter ?

Merci de votre aide,
Emmanuel

Bonjour, j’ai le même problème. Plus moyen de me connecter à ma Jeedom. Je suis rentré à la maison ce matin après 15 jours d’absence et impossible de me connecter pour désactiver l’alarme. J’ai dû démonter manuellement mon alarme, à la grande joie des voisins. Quand je veux rentrer dans Jeedom, je boucle sur l’écran d’accès vert ou je reçois ce message d’erreur “SQLSTATE[HY000] [2002] Connection refused”. Que faire ? J’ai essayé de débrancher et rebrancher ma Smart, rien ne change. Je dois pouvoir accéder à Jeedom pour remettre mon chauffage en route. Merci d’avance.

Bonjour,
J’ai contacté l’équipe Domadoo qui m’a proposé 4 solutions :

Les 3 premières n’ayant pas fonctionné, j’ai fait un recovery de la smart.
Cela m’a permis de réinstaller un back-up d’une configuration qui était OK. J’en ai profité pour faire la mise à jour et obtenir la dernière version de Jeedom car j’étais en 3.3.24
Du coup, j’ai pu mettre mon chauffage en mode “présent”. Et je me croyais sauvé.
J’ai fait une synchronisation Zwave pour récupérer les derniers équipements que j’avais installé après le back-up (3 pinces ampérimétriques).
J’ai également désactivé les plugins Blea et Xiaomi qui avaient des problèmes de démarrage du démon (3 essais infructueux). Je pensais régler cela plus tard.
Et puis ce matin, je me retrouve de nouveau avec le même problème. Plus d’accès à Jeedom et des scénarios qui ne s’exécutent pas.
Retour case départ.

Je me suis reconnecté en ssh et voici ce que j’obtiens :
root@jeedom:/# ls -lsh
total 257M
4.0K drwxr-xr-x 2 root root 4.0K Jan 1 1970 bin
4.0K drwxr-xr-x 2 root root 4.0K Jan 17 2016 boot
0 drwxr-xr-x 18 root root 14K Dec 20 14:19 dev
4.0K drwxr-xr-x 92 root root 4.0K Dec 20 13:59 etc
4.0K drwxr-xr-x 3 root root 4.0K Mar 2 2017 home
4.0K drwxr-xr-x 14 root root 4.0K Dec 20 13:56 lib
16K drwx------ 2 root root 16K Feb 8 2016 lost+found
4.0K drwxr-xr-x 11 root root 4.0K Mar 14 2017 media
4.0K drwxr-xr-x 2 root root 4.0K Feb 5 2016 mnt
4.0K drwxr-xr-x 4 root root 4.0K Apr 29 2019 opt
0 dr-xr-xr-x 137 root root 0 Jan 1 1970 proc
4.0K drwx------ 9 root root 4.0K Oct 1 2018 root
0 drwxr-xr-x 22 root root 720 Dec 22 08:15 run
4.0K drwxr-xr-x 2 root root 4.0K Dec 20 13:56 sbin
4.0K drwxr-xr-x 2 root root 4.0K Feb 5 2016 srv
257M -rw------- 1 root root 256M Mar 14 2017 swapfile1
0 dr-xr-xr-x 12 root root 0 Dec 22 08:18 sys
0 drwxrwxrwt 10 root root 220 Dec 22 08:20 tmp
4.0K drwxr-sr-x 10 root root 4.0K Mar 10 2016 usr
4.0K drwxr-xr-x 12 root root 4.0K Mar 2 2017 var

root@jeedom:/# df -h
Filesystem Size Used Avail Use% Mounted on
udev 732M 0 732M 0% /dev
tmpfs 172M 22M 150M 13% /run
/dev/mmcblk0p7 6.5G 6.2G 0 100% /
tmpfs 859M 0 859M 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 859M 0 859M 0% /sys/fs/cgroup
tmpfs 256M 4.0K 256M 1% /tmp
tmpfs 128M 6.2M 122M 5% /tmp/jeedom
/dev/mmcblk0p1 253M 101M 152M 40% /media/boot

root@jeedom:/var/lib/mysql#
ls -lsh
total 91M
16K -rw-rw---- 1 mysql mysql 16K Apr 29 2019 aria_log.00000001
4.0K -rw-rw---- 1 mysql mysql 52 Apr 29 2019 aria_log_control
0 -rw-r–r-- 1 root root 0 Mar 9 2018 debian-10.1.flag
26M -rw-rw---- 1 mysql mysql 26M Dec 22 08:19 ibdata1
32M -rw-rw---- 1 mysql mysql 32M Dec 22 08:19 ib_logfile0
32M -rw-rw---- 1 mysql mysql 32M Dec 21 17:36 ib_logfile1
4.0K drwx------ 2 mysql mysql 4.0K Dec 21 23:00 jeedom
0 -rw-rw---- 1 mysql mysql 0 Mar 9 2018 multi-master.info
4.0K drwx------ 2 mysql mysql 4.0K Mar 9 2018 mysql
4.0K -rw------- 1 mysql mysql 6 Mar 9 2018 mysql_upgrade_info
4.0K drwx------ 2 mysql mysql 4.0K Mar 9 2018 performance_schema
24K -rw-rw---- 1 mysql mysql 24K Nov 3 2016 tc.log

root@jeedom:/var/log#
ls -lsh
total 11M
0 -rw-r–r-- 1 root root 0 Dec 21 06:25 alternatives.log
4.0K -rw-r–r-- 1 root root 243 Dec 20 13:59 alternatives.log.1
4.0K -rw-r–r-- 1 root root 272 Dec 20 13:57 apcupsd.events
4.0K drwxr-xr-x 2 root root 4.0K Dec 21 06:25 apt
156K -rw-r----- 1 root adm 150K Dec 22 08:46 auth.log
1.7M -rw-r----- 1 root adm 1.7M Dec 22 06:25 auth.log.1
108K -rw-r----- 1 root adm 107K Dec 21 06:25 auth.log.2.gz
0 -rw-rw---- 1 root utmp 0 Dec 21 06:25 btmp
4.0K -rw------- 1 root utmp 2.8K Apr 29 2019 btmp.1
4.0K -rw-r----- 1 root adm 1.6K Dec 22 08:39 daemon.log
3.7M -rw-r----- 1 root adm 3.6M Dec 22 06:09 daemon.log.1
12K -rw-r----- 1 root adm 8.6K Dec 21 06:09 daemon.log.2.gz
0 -rw-r----- 1 root adm 0 Dec 21 06:25 debug
4.0K -rw-r----- 1 root adm 1.3K Nov 3 2016 debug.1
0 -rw-r–r-- 1 root root 0 Dec 21 06:25 dpkg.log
20K -rw-r–r-- 1 root root 18K Dec 20 13:59 dpkg.log.1
4.0K -rw-r----- 1 root adm 214 Dec 22 06:25 fail2ban.log
4.0K -rw-r----- 1 root adm 214 Dec 21 06:25 fail2ban.log.1
4.0K -rw------- 1 root root 745 Nov 3 2016 fail2ban.log.2.gz
0 -rw-r----- 1 root adm 0 Dec 21 06:25 kern.log
160K -rw-r----- 1 root adm 160K Dec 20 14:19 kern.log.1
4.0K -rw-r----- 1 root adm 157 Dec 22 06:25 messages
4.0K -rw-r----- 1 root adm 314 Dec 22 06:25 messages.1
32K -rw-r----- 1 root adm 31K Dec 21 06:25 messages.2.gz
4.0K -rw------- 1 root root 56 Dec 22 06:25 php7.0-fpm.log
4.0K -rw------- 1 root root 466 Nov 3 2016 php7.0-fpm.log.1
64K -rw-r----- 1 root adm 59K Dec 22 08:46 syslog
4.2M -rw-r----- 1 root adm 4.2M Dec 22 06:25 syslog.1
64K -rw-r----- 1 root adm 64K Dec 21 06:25 syslog.2.gz
4.0K drwxr-xr-x 2 root root 4.0K Oct 1 2018 unattended-upgrades
0 -rw-r----- 1 root adm 0 Dec 21 06:25 user.log
4.0K -rw-r----- 1 root adm 823 Dec 20 14:19 user.log.1
4.0K -rw-rw-r-- 1 root utmp 400 Dec 22 08:15 wtmp
8.0K -rw-rw-r-- 1 root utmp 5.9K Dec 20 13:27 wtmp.1

A noter que j’ai également supprimé les logfile dans MySQL et retenté un start de MySQL, sans succès.

Appel aux spécialistes, voyez-vous quelque chose d’anormal ?
Sinon, je pense recommencer la procédure recovery début d’après-midi et désactiver mes 3 pinces ampérimétriques en “espérant” que ce soient elles qui sont à la source de mon problème.

Merci d’avance.
Pascal

Pour le cas où cela pourrait servir à un autre utilisateur :
J’ai fait un reboot via SSH (commande “shutdown -r now”) et cela a permis de me reconnecter après quelques minutes.
Cela a supprimé des fichiers sur la partition root qui était saturée avant ce reboot.
Mais j’ai constaté que tous mes scénarios horaires (programmés pour se lancer à une heure précise une fois par jour) démarraient toutes les minutes sans que j’en comprenne la raison. J’ai désactivé tous mes scénarios horaires et arrêté les cron (dans le moteur de tâches).
J’ai désactivé mes pinces ampérimétriques (seul changement récent dans Jeedom et postérieur à mon back-up).
Je me suis déconnecté et reconnecté à Jeedom et pour le moment, Jeedom semble refonctionner normalement. J’ai réactivé les scénarios un à un en vérifiant qu’ils ne se lançaient pas. Je croise donc les doigts pour que le problème soit résolu mais si quelqu’un a une explication ou une théorie, je le remercie d’avance.

J’attend un peu avant d’essayer de régler le problème des plugins Blea (pour mes MiFlora) et Xiaomi (pour mon aspirateur) et réactiver mes pinces ampérimétriques qui me permettent de suivre la consommation de ma pompe à chaleur, de ma filtration et de mon déshumidificateur de la piscine.

Pascal