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

Jeedom-Market · octobre 23, 2020, 3:08pm

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 · novembre 4, 2020, 10:51am

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 · novembre 4, 2020, 10:51am

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 · novembre 4, 2020, 10:52am

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

Pet1Cable · juin 1, 2020, 10:19am

Bonjour @tous

Je suis passé par le même type d’installation afin d’installer des plugins qui nécessitent plus de puissance de calcul.

Je ne peux que souligner les réponses d’Akenad à savoir utiliser au tout début de l’installation de Debian 10 la commande

su - (su espace tiret et rien derrière)

Explication:

Now, what’s the difference between ‹ su › and ‹ su - › ? Well, the former keeps the environment of the old/original user even after the switch to root has been made, while the latter creates a new environment (as dictated by the ~/.bashrc of the root user), similar to the case when you explicitly log in as root user from the log-in screen.

IMPORTANT for Debian 10 users. The PATH variable of the root user differs on Debian 10 when using ‹ su › vs ‹ su - ›, directories like /sbin are missing when only ‹ su › is used which means that you might get command not found errors even for basic system administration commands. So always use ‹ su - › on Debian 10 to become root user.

Dans la langue de Molière cela signifie qu’une petite spécification à été ajoutée pour Debian Buster 10 et que seule la commande précitée invoque les droits ROOT (pas seulement admin).
Il n’y a aucunes autres alternatives que cette commande pour installer le script Jeedom car la création de la base de donnée nécessite obligatoirement des droits ROOT.
D’où toutes les erreurs que vous obtenez …

Conclusion:
1/ Retour à la case départ (Vm ou non) et recommencer toute l’installation du début
2/ Ecoute Akenad c’est un sage

A tous je vous souhaite une bonne réinstallation … vous y êtes presque …

P.

lilouane14 · juin 1, 2020, 6:46pm

Bonsoir,
je suis d’accord … mais j’ai effectué l’installation en su -
c’est précisé dans la documentation je l’ai respectée …
je pense que le pbm vient d’ailleurs, il arrive parfoit que la VM reboot sans ce blocage … pourquoi ?

rhoazon · juin 3, 2020, 8:49pm

idem, installation faite après un « su - » , de temps en temps la VM s’arrête proprement mais en majorité je dois forcer l’arrêt.

arnog23 · octobre 20, 2020, 1:43pm

Bonjour,

Quelqu’un a t-il trouver une solution ?

L’utilisation de « su - » comme indiqué par @akenad ne resoud pas le problème pour moi.

En revanche, j’ai testé avec l’image jeedom-debian-buster-amd64-4.0.61.iso et aucun soucis.

Cela ne semble donc pas venir de la paire Jeedom/Buster comme évoqué par @Yves19

Je pourrais partir sur l’image disponible mais j’aimerais bien comprendre d’ou cela vient.

Yves19 · octobre 20, 2020, 3:10pm

En fait j’ai peut être résolu mon problème en faisant :

synchronisation des horloges sur l’heure UTC plutôt que locales (option de configuration de Debian donc à bien paramétrer)
Horloge RTC du NUC a laisser sur heure UTC itou
Forcer le shut down de la base de données au bout de 1min plutôt que 15 ou 20 min comme paramétré par défaut

Avec ces trois actions, plus de soucis (en tous cas je n’ai pas vu réapparaître la mise en œuvre de la troisième depuis)…
Le problème venait que l’heure Debian et celle de l’horloge RTC n’étaient pas exprimées dans le même fuseau et donc les heures calculées par la BDD au moment du shut down étaient décalées de 2 heures (entre heure de Paris et heure UTC)…Résultat des courses une vérification de cohérence impossible à terminer et donc passage en time out du shut down de maria DB , lequel time out est par défaut de 15 ou 20 min je crois.

arnog23 · octobre 20, 2020, 4:03pm

Si je compare les 2 VM (Celle faite manuellement et celle faite à partir de l’iso), elles sont toutes les 2 en UTC+2 et mon NUC est en UTC. Si cela venait de l’horloge, cela arriverait à chaque fois alors que cela semble aléatoire, non ?

Je pencherais plutôt pour ta 3e action qui ne fait que masquer le soucis finalement, non ?

Yves19 · décembre 9, 2020, 11:59am

Pour moi clairement c’était le décalage entre UTC et Local qui posait pb.
J’avais remarqué que cela se produisait sur des redémarrages à chaud et pas sur des redémarrages à froid.
Une fois que j’ai compris que l’horloge du NUC était synchronisée sur celle que je recalais à la main sur Debian j’ai tilté avec l’aide du support en ligne Intel USA (que je salue au passage).

Don c sous Debian s’assurer que l’heure est bien réglée sur UTC avec
timedatectl set-local-rtc 0

Faire de même sur l’horloge RTC du BIOS du NUC

et là bingo plus d’heure dans le futur coté mariadb et plus d’alerte au poweroff.

Pas acquis de conscience j’ai aussi configuré mariadb en mettant
TimeoutStopSec=60
dans
/lib/systemd/system/mariadb.service
Cette dernière action est juste là comme tu le soulignes pour réduire les conséquences du problème s’il survenait de nouveau.