Problème mise à jour 4.2.21 -> 4.3.17 (Centre de mise à jour -> fichier introuvable ok.repo.php)

LaurentA · Juin 11, 2023, 4:32

Bonjour

Je tourne sur docker/raspberry et je tente de mettre à jour jeedom depuis la version 4.2.21 vers une 4.3 qui est un prérequis pour le plugin jeeZigbee.

La mise à jour semble bien se passer (voir log) mais dans l’écran mise à jour lorsque je recherche manuellement j’ai une popup rouge :

Cette erreur se retrouve également dans la page de certains plugins (d’un âge avancé). Dans ce cas on n’a plus accès aux contrôles de la gestion du plugin.
Exemple :

Enfin le plugin RFXCom ne démarre plus en 4.3.17

Voici la page santé :

Bref, je vais recharger une sauvegarde en 4.2.21 mais impossible pour moi d’installer jeeZigbee que je viens d’acheter (et impossible d’acheter l’ancien plugin zigbee officiel qui indique qu’il faut installer jeeZigbee).

Est-ce que quelqu’un d’autre a eu ce souci ?

Voici la log de l’update :
update.txt (5,8 Ko)

anon53349806 · Juin 11, 2023, 5:51

Sous docker c’est pas le container quil fqut mettre a jour ? Au lieu de jeedom lui meme ?

LaurentA · Juin 12, 2023, 5:36

Je n’avais pas compris ça comme ça, personnellement j’ai toujours mis à jour jeedom depuis l’interface standard sans aucun problème (sauf quand j’ai dû passer en buster pour la 4.0).

Ceci dit, je ne comprends pas pourquoi une image linux ferait une différence sur l’absence du fichier core/repo/ok.repo.php
Pour le coup, ça ressemble à fichier du core qui ne s’est pas correctement installé.

J’ai vérifié dans le répertoire en question et ce fichier est bien absent

pifou · Juin 14, 2023, 7:54

Non, si tu met à jour le container Jeedom, au lieu de Jeedom lui-même, dans ce cas il faut relancer les dépendances de tous les plugins, il n’y a pas de procédure automatisée pour cela pour l’instant.

@LaurentA
le fichier /core/repo/ok.repo.php n’existe pas. Certains ont eu un problème similaire à cause d’une traduction automatique qui recherchait le fichier « marché.repo.php »

c’est une piste… A-tu plus de logs dans le log http.error peut être ?

LaurentA · Juin 14, 2023, 3:52

Merci @pifou pour ta réponse

J’avais lu le fil de ce problème de traduction dont tu parles mais sans succès.
Je suis repassé en 4.2 pour le moment mais je repasserai en 4.3 ce weekend pour faire plus de tests.
Actuellement les logs que j’ai dans /var/log/apache2/errors.log n’ont pas l’air d’avoir de lien avec mon problème (j’ai testé errors.log.1 et errors.log.2 au cas où.

Par contre je n’ai pas trouvé les logs PHP où je devrais voir les erreurs de fichier ok.repo.php non trouvé, une idée ?

Je ne pense pas que ce soit lié mais je le mentionne à tout hasard : un souci que j’ai remarqué sur mon système c’est que jeedom a l’air configuré pour utiliser serviced/systemctl alors que mon image docker démarre en SysV et utilise la commande service. Ca me pose quelques soucis dans certains plugins et je pense qu’il va falloir que je migre vers une image buster configurée avec systemd

Bref, je posterai le résultat de mes recherches ce weekend après ma remigration en 4.3

pifou · Juin 14, 2023, 7:56

Tu a regardé dans les logs de Jeedom en particulier http.error ? pour moi c’est la, c’est les logs d’erreur php.

Pour la différence systemctl / service dans un container Docker c’est un sujet ardu. Pour moi il faudrait remplacer par le supervisord. Mais pour l’instant c’est fait comme Jeedom normal - pas dans un container docker - donc ça devrait marcher, à la différence que l’image Debian pour Docker n’est peut être pas tout à fait identique au Debian qu’on installe sur un système physique. ça vaudrait le coup d’ouvrir un sujet ici dans cette section pour les démons / plugins concernés.

LaurentA · Juin 15, 2023, 12:34

Hello,
J’ai fini par comprendre qu’il s’agissait du log jeedom dans Analyses → Logs

Bon, pas de ligne de type http.error dans ce log (l’erreur de fichier absent ok.repo.php n’y apparaît pas.
J’y ai cependant retrouvé le résultat d’un test que j’avais fait lorsque j’étais en 4.3 :

Pour debugger ce problème de fichier absent, j’avais fait un lien symbolique ok.repo.php → market.repo.php
Cette astuce résolvait (naturellement) le problème de fichier absent, mais évidemment jeedom ne trouvait pas ce qu’il cherchait dans le fichier ok.repo.php et on échouait sur une erreur qui se retrouve dans le log jeedom :

// Quelques erreurs de 2022
0004|[2023-06-07 10:21:05]ERROR : Class 'repo_ok' not found

Bref, quelque-chose dans jeedom recherche la classe repo.ok dans le fichier core/repo/ok.repo.php

Lorsqu’on est sur la page mise à jour
Lorsqu’on est sur la page de management de certains plugins

Evidemment, la commande grep -r "ok.repo.php" /var/www/html/ ne renvoie aucun résultat.

Mais pour l’instant c’est fait comme Jeedom normal - pas dans un container docker - donc ça devrait marcher, à la différence que l’image Debian pour Docker n’est peut être pas tout à fait identique au Debian qu’on installe sur un système physique. ça vaudrait le coup d’ouvrir un sujet ici dans cette section pour les démons / plugins concernés.

J’avais cru lire que les utilisateurs docker n’étaient pas trop fan d’avoir des debian en systemd/systemctl ce qui pourrait expliquer une différence (certaines images buster sont explicitement référencées sur docker comme ‹ with systemd support ›), je vais investiguer de mon côté.

Pour les plugins, j’ai eu notamment des soucis avec le lancement du démon mosquitto du plugin officiel mqtt2, voir cette réponse

En tout cas merci de ton aide !

Update:

Je viens de me rendre compte que ce problème de systemd apparaît aussi pendant l’update 4.2 → 4.3 : voici un extrait du log de mise à jour (posté au premier post de ce fil)

[PROGRESS][55]
Update system into : 4.3.0...OK
Update system into : 4.3.8...OK
Update system into : 4.3.16...System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
OK

Il doit y avoir le démarrage d’un service au moment de l’update incrémental vers 4.3.16
Celui-ci ne peut s’executer (car il aurait fallu utiliser service plutôt que systemctl incompatible avec mon image buster docker).
Peut-être est-ce lié au problème ?

pifou · Juin 15, 2023, 2:56

Cette erreur concerne fail2ban donc je ne pense pas lié à ton problème…

github.com

jeedom/core/blob/12a7fffb4262aa04e36294011d81d1b513be5137/install/update/4.3.16.php#L5

      
        
            <?php
            require_once __DIR__ . '/../../core/php/core.inc.php';
            shell_exec('sudo rm /etc/fail2ban/jail.d/jeedom.conf');
            shell_exec('sudo cp ' . __DIR__ . '/../../install/fail2ban.jeedom.conf /etc/fail2ban/jail.d/jeedom.conf');
            shell_exec('sudo systemctl restart fail2ban');

Le nom de la classe ou du fichier est dynamique, ce qui rend compliqué de le retrouver d’un simple grep.
$class = 'repo_' . $name; et reste à trouver comment on a ‹ ok › dans la variable $name

LaurentA · Juin 15, 2023, 3:10

Merci @pifou cette info est très utile
Je vais repasser en 4.3 ce weekend et essayer de traquer l’appelant de cette fonction / fichier.
Je post des news si j’en ai.

pifou · Juin 15, 2023, 3:14

Si tu reproduis le bug, essaye de voir dans la table update, la source qui est market ou github dans la plupart des cas, et la colonne suivante status qui vaut « ok ». Je soupçonne un décalage des colonnes quelque part.

SELECT * FROM `update`