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)
.
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 ?
Bonjour,
as-tu fais :
$ su -
Avant d’installer jeedom ?
Plus de détails ici : https://community.jeedom.com/t/2510
akenad 
#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
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…
Je ne peux pas te dire plus que bien lire et suivre du début à la fin.
akenad
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.
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
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 ?
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
Ç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 ?
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)
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
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.
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 ?
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.