Problème après installation de JeedomV4 sur Debian Buster

Jeedom-Market · mai 2, 2020, 7:57am

Page : index.php?v=d&p=dashboard
Jeedom_version : 4.0.52
Uname : Linux JeedomV4 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1+deb10u1 (2020-04-27) x86_64 GNU/Linux

Message :
Bonjour, j’ai fait une primo install de debian buster + jeedom v4 (pour ensuite restaurer jeedom v3 et migrer pour voir si tout fonctionne correctement plutot que de migrer direcetement mon jeedom v3 de prod sur strech). Suite à l’install de jeedom V4, ma VM debian ne s’arrete pas correctement et je suis obligé de forcer l’arret (j’ai « a stop job is running for MariaDB 10.3.22 database server ») . Au démarrage suivant, je me retrouve avec des inode ophelin, mais Debian démarre quand même.
J’ai édité error.log dans /var/log/mysql , j’ai à la dernière ligne:
2020-05-02 10:38:42 10 [Warning] Access denied for user ‹ root ›@‹ localhost › (using password: NO)
L’heure n’est pas bonne puisque j’ai un décalage +2h par rapport à l’heure SYSTEM
AUtre chose, dans Jeedom, quand je vais dans « réglages-système-configuration-_OS/DB » je vois un mot de passe dans « utilisateur/mot de passe » différent de celui qui m’a été donné à la fin de l’install en ligne de commande (./install.sh) mais je ne sais pas si c’est normal ou pas.
Cela fait deux fois que je fais la réinstall complète debian+jeedom, d’ou mon post.
J’ai consulté plusieurs sites, vérifier les fichiers conf de mysql, je n’ai pas vu d’anomalies.
Je n’avais eu aucun soucis avec la primo install de debian strech + jeedom V3 , donc je ne comprends pas le soucis aujourdh’ui avec cette nouvelle version.
Avant de maniper sur les droits de la BDD je préfère faire une demande de support
Merci

PS:
cat /var/log/mysqlError.log
2020-05-02 10:38:39 0 [Warning] The parameter innodb_large_prefix is deprecated and has no effect. It may be removed in future releases. See https://mariadb.com/kb/en/library/xtradbinnodb-file-format/
2020-05-02 10:38:39 0 [Note] InnoDB: Using Linux native AIO
2020-05-02 10:38:39 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-05-02 10:38:39 0 [Note] InnoDB: Uses event mutexes
2020-05-02 10:38:39 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-05-02 10:38:39 0 [Note] InnoDB: Number of pools: 1
2020-05-02 10:38:39 0 [Note] InnoDB: Using SSE2 crc32 instructions
2020-05-02 10:38:39 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2020-05-02 10:38:39 0 [Note] InnoDB: Completed initialization of buffer pool
2020-05-02 10:38:39 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2020-05-02 10:38:39 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=2150416
2020-05-02 10:38:41 0 [Note] InnoDB: Starting final batch to recover 1 pages from redo log.
2020-05-02 10:38:41 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2020-05-02 10:38:41 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2020-05-02 10:38:41 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-05-02 10:38:41 0 [Note] InnoDB: Setting file ‹ ./ibtmp1 › size to 12 MB. Physically writing the file full; Please wait …
2020-05-02 10:38:41 0 [Note] InnoDB: File ‹ ./ibtmp1 › size is now 12 MB.
2020-05-02 10:38:41 0 [Note] InnoDB: Waiting for purge to start
2020-05-02 10:38:41 0 [Note] InnoDB: 10.3.22 started; log sequence number 2150706; transaction id 1099
2020-05-02 10:38:41 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2020-05-02 10:38:41 0 [Note] InnoDB: Buffer pool(s) load completed at 200502 10:38:41 (/var/lib/mysql/ib_buffer_pool was empty)
2020-05-02 10:38:41 0 [Note] Plugin ‹ FEEDBACK › is disabled.
2020-05-02 10:38:41 0 [Note] Recovering after a crash using tc.log
2020-05-02 10:38:41 0 [Note] Starting crash recovery…
2020-05-02 10:38:41 0 [Note] Crash recovery finished.
2020-05-02 10:38:41 0 [Note] Server socket created on IP: ‹ 127.0.0.1 ›.
2020-05-02 10:38:42 0 [Note] Reading of all Master_info entries succeeded
2020-05-02 10:38:42 0 [Note] Added new Master_info ‹ › to hash table
2020-05-02 10:38:42 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: ‹ 10.3.22-MariaDB-0+deb10u1 › socket: ‹ /run/mysqld/mysqld.sock › port: 3306 Debian 10
2020-05-02 10:38:42 8 [Warning] Access denied for user ‹ root ›@‹ localhost › (using password: NO)
2020-05-02 10:38:42 9 [Warning] Access denied for user ‹ root ›@‹ localhost › (using password: NO)
2020-05-02 10:38:42 10 [Warning] Access denied for user ‹ root ›@‹ localhost › (using password: NO)
.

Idaho947 · mai 2, 2020, 9:01am

Je n’ai pas de réponse pour ton problème spécifique mais tu sais que si tu restaure un bak v3 sur une v4 tu reviens en v3 ?

akenad · mai 2, 2020, 9:19am

Bonjour,

as-tu fais :
$ su -
Avant d’installer jeedom ?

Plus de détails ici : https://community.jeedom.com/t/2510

akenad

rhoazon · mai 2, 2020, 9:59am

#Idaho947
oui, mais je voulais tester la v4 et avoir un système clean avant de restaurer.

#akenad
j’ai lancé l’install après un sudo su

rhoazon · mai 2, 2020, 12:14pm

Je viens de refaire l’installation de jeedom sur une VM debian buster vierge en ayant bien fait su - avant d’éxecuter …/install.sh
Installation finie…je regarde le /var/log/mysql/error.log , pareil:
2020-05-02 14:04:51 10 [Warning] Access denied for user ‹ root ›@‹ localhost › (using password: NO)

Par rapport au post " [RTEX] Debian 10 - Buster - netinst - amd64 - Jeedom V4" , la différence maintenant est que le script install.sh lance la version 4 de jeedom…

akenad · mai 2, 2020, 12:20pm

Je ne peux pas te dire plus que bien lire et suivre du début à la fin.

akenad

rhoazon · mai 2, 2020, 2:05pm

Bah je crois que je vais laisser tomber car je pense bien avoir suivi la procédure. En PJ log install jeedomv4.pdf (439,9 Ko)
le log copier-coller de ma session terminal du « su - » a la fin de l’install de jeedom… pas grave si tu n’a pas le temps de jeter un oeil, je veux pas abuser.

akenad · mai 2, 2020, 4:01pm

Apparemment il y a eu des modifications depuis quelques jours dans : https://raw.githubusercontent.com/jeedom/core/master/install/install.sh
en particulier à partir de l’étape 7.
Ce qui pourrait expliquer un changement de comportement dans l’installation de Jeedom.
Est-ce que tu accèdes à l’interface IHM Jeedom ?

Le mot de passe indiqué à la fin du install.sh est le mot de passe root MySQL, tandis que le mot de passe indiqué dans OS/DB est le mot de passe de l’utilisateur jeedom MySQL.

akenad

rhoazon · mai 2, 2020, 9:51pm

Oui , accès à l’IHM Jeedom, changement du mot de passe admin…tout à l’air normal. Sauf que quand je veux arreter le serveur debian, il ne s’arrete pas sans le forcer car il n’arrive pas à stopper la base de données (a stop job is running for mariaDB 10.3.22 data base server)…et qu’en creusant j’ai vu le log d’erreur mysql. L’etape 3 du script install.sh a Bien changé depuis la v3 avec la v4 et les différences se font entre mysql et mariaDB…C’est peut être lié a mon pb ?

Yves19 · mai 2, 2020, 10:22pm

Pour moi pareil. Une fois sur quatre lors de l’arrêt de mon NUC Buster Jeedom V4.0.52 l’arrêt reste bloqué indéfiniment sur a stop jod is running for mariaDB …
Mais j’ai aussi le même comportement sur la dernière version 3 de Jeedopm sous Buster.

Je pense que le pb vient donc de la paire Jeedom/Buster.

Aucun pb avec version 3 de Jeedom sous Stretch sur le NUC

rhoazon · mai 3, 2020, 7:26am

Ça me rassure quelque part de voir que je ne suis pas le seul à rencontrer le soucis. C’est problématique d’arrêter une BDD en forçant l’arrêt, donc je ne passerai pas mon jeedom sous Buster tant que le problème ne sera pas résolu.
Est-ce que tu as aussi un fichier error.log sous /var/log/mysql/ et quel est son contenu ?

rhoazon · mai 4, 2020, 9:50pm

Je continue d’investiguer un peu…j’ai été regardé la table des droits de mysql, et les droits de root :
sur debian 9 (OK) :
MariaDB [(none)]> show grants for root@localhost;
±-----------------------------------------------------------------------------------------------+
| Grants for root@localhost |
±-----------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON . TO ‹ root ›@‹ localhost › IDENTIFIED VIA unix_socket WITH GRANT OPTION |
| GRANT PROXY ON ‹ ›@’%’ TO ‹ root ›@‹ localhost › WITH GRANT OPTION |
±-----------------------------------------------------------------------------------------------+
2 rows in set (0.04 sec)

Sur Debian 10 (KO) :
MariaDB [(none)]> show grants for root@localhost;
±---------------------------------------------------------------------------------------------------------------------------------------+
| Grants for root@localhost |
±---------------------------------------------------------------------------------------------------------------------------------------+
*| GRANT ALL PRIVILEGES ON . TO ‹ root ›@‹ localhost › IDENTIFIED BY PASSWORD '5E154B50E6E61F337D87EDFB243DF43E015D1FEC’ WITH GRANT OPTION |
| GRANT PROXY ON ‹ ›@’%’ TO ‹ root ›@‹ localhost › WITH GRANT OPTION |
±---------------------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.000 sec)

lilouane14 · mai 31, 2020, 10:22am

Bonjour,

je rencontre la même problématique avec debian10 buster.
si je reboot jeedom ma VM reste sur a stop job is running for mariaDB

obliger de rebooter la VM de force.
j’ai également trouver [Warning] Access denied for user ‹ root ›@‹ localhost › (using password: NO) dans les log :
2020-05-31 12:14:43 33 [Warning] Aborted connection 33 to db: ‹ jeedom › user: ‹ jeedom › host: ‹ localhost › (Got an error reading communication packets)
2020-05-31 12:15:18 0 [Note] /usr/sbin/mysqld (initiated by: unknown): Normal shutdown
2020-05-31 12:15:18 0 [Note] Event Scheduler: Purging the queue. 0 events
2020-05-31 12:15:18 0 [Note] InnoDB: FTS optimize thread exiting.
2020-05-31 12:15:18 0 [Note] InnoDB: Starting shutdown…
2020-05-31 12:15:18 0 [Note] InnoDB: Dumping buffer pool(s) to /var/lib/mysql/ib_buffer_pool
2020-05-31 12:15:18 0 [Note] InnoDB: Buffer pool(s) dump completed at 200531 12:15:18
2020-05-31 12:16:54 0 [Warning] The parameter innodb_large_prefix is deprecated and has no effect. It may be removed in future releases. See https://mariadb.com/kb/en/library/xtradbinnodb-file-format/
2020-05-31 12:16:54 0 [Note] InnoDB: Using Linux native AIO
2020-05-31 12:16:54 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-05-31 12:16:54 0 [Note] InnoDB: Uses event mutexes
2020-05-31 12:16:54 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-05-31 12:16:54 0 [Note] InnoDB: Number of pools: 1
2020-05-31 12:16:54 0 [Note] InnoDB: Using SSE2 crc32 instructions
2020-05-31 12:16:54 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2020-05-31 12:16:54 0 [Note] InnoDB: Completed initialization of buffer pool
2020-05-31 12:16:54 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2020-05-31 12:16:54 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=7486402
2020-05-31 12:16:55 0 [Note] InnoDB: Starting final batch to recover 17 pages from redo log.
2020-05-31 14:16:42 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2020-05-31 14:16:42 0 [Note] InnoDB: Removed temporary tablespace data file: « ibtmp1 »
2020-05-31 14:16:42 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-05-31 14:16:42 0 [Note] InnoDB: Setting file ‹ ./ibtmp1 › size to 12 MB. Physically writing the file full; Please wait …
2020-05-31 14:16:42 0 [Note] InnoDB: File ‹ ./ibtmp1 › size is now 12 MB.
2020-05-31 14:16:42 0 [Note] InnoDB: Waiting for purge to start
2020-05-31 14:16:42 0 [Note] InnoDB: 10.3.22 started; log sequence number 7567299; transaction id 10296
2020-05-31 14:16:42 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2020-05-31 14:16:42 0 [Note] Plugin ‹ FEEDBACK › is disabled.
2020-05-31 14:16:42 0 [Note] Recovering after a crash using tc.log
2020-05-31 14:16:42 0 [Note] Starting crash recovery…
2020-05-31 14:16:42 0 [Note] Crash recovery finished.
2020-05-31 14:16:42 0 [Note] Server socket created on IP: ‹ 127.0.0.1 ›.
2020-05-31 14:16:42 0 [Note] Reading of all Master_info entries succeeded
2020-05-31 14:16:42 0 [Note] Added new Master_info ‹ › to hash table
2020-05-31 14:16:42 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: ‹ 10.3.22-MariaDB-0+deb10u1 › socket: ‹ /run/mysqld/mysqld.sock › port: 3306 Debian 10
2020-05-31 14:16:42 0 [Note] InnoDB: Buffer pool(s) load completed at 200531 14:16:42
2020-05-31 14:16:42 8 [Warning] Access denied for user ‹ root ›@‹ localhost › (using password: NO)
2020-05-31 14:16:42 9 [Warning] Access denied for user ‹ root ›@‹ localhost › (using password: NO)
2020-05-31 14:16:42 10 [Warning] Access denied for user ‹ root ›@‹ localhost › (using password: NO)

voilà mes logs si sa peut aider a resoudre le pbm
merci