Écran de connexion en boucle

Bonjour à tous,

J’étais entrain de modifier un design quand j’ai voulu ajouter une image de fond. J’ai eu un message d’erreur comme quoi il était impossible de copier l’image dans un dossier temporaire. J’ai voulu me déconnecter et me reconnecter à ma box Jeedom.

Sauf que lors de la reconnexion, j’ai beau rentrer mot login et mot de passe, une fois le tout validé l’écran de connexion disparait pour réapparaitre, sans m’indiquer que le login ou mot de passe est incorrect.

J’ai bien entendu penser à déconnecter ma box Jeedom et la reconnecter mais pas mieux.

J’ai pensé à me connecter en ssh, mais lors de la première connexion après redémarrage de la box Jeedom ça mouline jusqu’à un time out, et après toutes les tentatives se soldent par « connection refused ».

Saturation du nombre de connections en admin ? Honnêtement je ne sais pas, et je ne sais pas quoi faire. Des idées ? Un moyen de se connecter en « local » ?

Merci de votre aide.

J’ai tenté plusieurs choses.

Depuis, j’ai ce message d’erreur en essayant d’accéder à l’IP de la box Jeedom : [SQLSTATE[HY000] [2002] Connection refused]

j’ai finalement pu me brancher en local sur la box par HDMI (j’ai la Jeedom smart). j’ai tenté plusieurs commandes soufflées par des personnes qui ont eu le même problème, rien n’a fonctionné.

j’ai donc voulu faire une restauration en suivant cette marche à suivre : https://jeedom.github.io/documentation/howto/fr_FR/recovery_mode_jeedom_smart

Mais une nouvelle fois, pas de résultat.

Je suis à court d’idée pour le moment.

un df -h me permet d’avoir ça :

Filesystem Size Used Avail Use% Mounted on
udev 732M 0 732M 0% /dev
tmpfs 172M 14M 159M 8% /run
/dev/mmcblk0p7 6.5G 6.2G 0 100% /
tmpfs 859M 0 859M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 859M 0 859M 0% /sys/fs/cgroup
tmpfs 256M 4.0K 256M 1% /tmp
tmpfs 128M 0 128M 0% /tmp/jeedom
/dev/mmcblk0p1 253M 101M 152M 40% /media/boot

Je pense que le soucis se situe à 100% utilisé par /dev/mmcblk0p7. Après quelques recherches je doute que sauvagement purger va régler le soucis. une idée ?

J’ai pense avoir trouvé le coupable :

262144 -rw------- 1 root root 268435456 Mar 14 2017 swapfile1

Mais maintenant je ne sais pas comment régler le problème…

Non la taille de swapfile1 est normale.

Pour repérer les répertoires qui ont une taille anormale, vous pouvez essayer avec cette commande:

sudo du -s /* | sort -rn

Sur ma Smart, ça donne:

1915712	/var
1778296	/usr
262148	/swapfile1
103121	/media
100036	/lib
97492	/root
41432	/run
30876	/opt
7864	/bin
7736	/tmp
6308	/etc
4992	/sbin
56	/home
16	/lost+found
4	/srv
4	/mnt
4	/boot
0	/sys
0	/proc
0	/dev

il faut ensuite progresser dans le répertoire de taille anormale en modifiant la commande.

sudo du -s /var/* | sort -rn

1331196	/var/www
481616	/var/lib
64284	/var/cache
31284	/var/log
7284	/var/backups
36	/var/spool
4	/var/tmp
4	/var/opt
4	/var/mail
4	/var/local
0	/var/run
0	/var/lock

Et ainsi de suite jusqu’à trouver ce qui a une taille anormale.

Ok merci je pense que je vais y arriver !

Je ne suis pas encore très habitué au fait que les système linux sont parfois moins bavards que les windows ou mac. Du coup je ne m’attendais pas à ce que la raison soit aussi simple que « le disque est plein » :slightly_smiling_face:

Pour comparer les valeurs, voici les tailles du répertoire où Jeedom est installé sur ma Smart:

780612	/var/www/html/backup
266140	/var/www/html/plugins
77480	/var/www/html/DB_backup.sql
60300	/var/www/html/3rdparty
29992	/var/www/html/core

La commande est :

sudo du -s /var/www/html/* | sort -rn

Mon / est utilisé à 66%

Pour rechercher les gros fichiers, vous avez cette commande:

sudo find /var/www/html -size +50M -print

Dans le répertoire de Jeedom et taille plus de 50 Mo.

Rebonjour à tous,

Alors j’ai tenté de faire le ménage. Je n’ai rien trouvé de très très gros. J’ai quand même pu supprimer certains fichier (plus de 900 Mo pour le fichier /etc/motion/motion.log)

Voici maintenant l’état de la box :

Filesystem      Size  Used Avail Use% Mounted on
udev            732M     0  732M   0% /dev
tmpfs           172M   11M  161M   7% /run
/dev/mmcblk0p7  6.5G  5.2G  945M  85% /
tmpfs           859M     0  859M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           859M     0  859M   0% /sys/fs/cgroup
tmpfs           256M     0  256M   0% /tmp
tmpfs           128M     0  128M   0% /tmp/jeedom
/dev/mmcblk0p1  253M  101M  152M  40% /media/boot

Je me suis dit donc que je pouvais reboot la box et continuer mon nettoyage sur l’interface… sauf que j’ai toujours cette erreur SQLSTATE[HY000] [2002] No such file or directory !

C’est pour cela que je me demande si maintenant le problème ne se situerait pas autre part que dans l’espace disponible.

J’ai donc essayer de démarrer mysql :

jeedom@jeedom:~$ sudo /etc/init.d/mysql start
[....] Starting mysql (via systemctl): mysql.serviceJob for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.
 failed!

et si je fais « systemctl status mariadb.service » :

jeedom@jeedom:~$ systemctl status mariadb.service
● mariadb.service - MariaDB database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/mariadb.service.d
           └─jeedom.conf
   Active: activating (start) since Wed 2020-05-13 18:58:54 UTC; 2s ago
  Process: 24252 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_re
  Process: 24247 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status
  Process: 24245 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=
 Main PID: 24448 (mysqld)
   CGroup: /system.slice/mariadb.service
           └─24448 /usr/sbin/mysqld

May 13 18:58:56 jeedom mysqld[24448]: 2020-05-13 18:58:56 547576315904 [Note] InnoDB: Completed initialization 
May 13 18:58:56 jeedom mysqld[24448]: 2020-05-13 18:58:56 547576315904 [Note] InnoDB: Highest supported file fo
May 13 18:58:56 jeedom mysqld[24448]: 2020-05-13 18:58:56 547576315904 [Note] InnoDB: 128 rollback segment(s) a
May 13 18:58:56 jeedom mysqld[24448]: 2020-05-13 18:58:56 547576315904 [Note] InnoDB: Waiting for purge to star
May 13 18:58:56 jeedom mysqld[24448]: 2020-05-13 18:58:56 547576315904 [Note] InnoDB:  Percona XtraDB (http://w
May 13 18:58:56 jeedom mysqld[24448]: 2020-05-13 18:58:56 546983374896 [Note] InnoDB: Dumping buffer pool(s) no
May 13 18:58:56 jeedom mysqld[24448]: 2020-05-13 18:58:56 547576315904 [Note] Plugin 'FEEDBACK' is disabled.
May 13 18:58:56 jeedom mysqld[24448]: 2020-05-13 18:58:56 547576315904 [Note] Recovering after a crash using tc
May 13 18:58:56 jeedom mysqld[24448]: 2020-05-13 18:58:56 547576315904 [ERROR] Can't init tc log
May 13 18:58:56 jeedom mysqld[24448]: 2020-05-13 18:58:56 547576315904 [ERROR] Aborting

et la je bloque…

un génie dans le coin ? :slight_smile:

Ok problème réglé ! après avoir fouillé sur le net j’ai tout simplement supprimer le fichier tc.log dans /var/lib/mysql et reboot.

Tout est revenu. Il va maintenant falloir faire le ménage.

Merci à tous pour votre aide

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.