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 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)
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.
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)*
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 …
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 ?
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.
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 ?
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.
