Mon Jeedom (bookworm) est installé sur un docker en McVLAN en suivant le tuto de @Didier3L, et tout se passe bien.
Mon docker est hébergé par mon NAS synologie DS218+.
J’ai une angoisse parfois : quand je reçois la notification qu’une nouvelle update est disponible pour mon NAS, genre un patch de sécurité par exemple… Ou parfois une mise à jour de l’appli Container manager.
En gros je ne sais pas comment être sûr de « fermer » Jeedom (et mes autres dockers) proprement pour lancer la mise à jour.
La commande « éteindre » dans Jeedom ne fait absolument rien quand ça tourne dans un docker (de ce que j’ai pu observé).
En effet, il m’est arrivé à deux reprises (une fois en lançant une mise à jour NAS, une fois en lançant une mise à jour de l’applic Container Manager du NAS, qu’à la suite de la mise à jour, mon Jeedom était corrompu et me laissant une erreur sur la page web :
Sans solution j’avais par deux fois dû tout réinstaller (j’ai mes sauvegardes mais quand même !)
Du coup je ne sais pas si simplement en lançant les commande STOP sur tous mes dockers (et donc sur mon docker jeedom), ça me met à l’abris de ce genre de problème.
Donc simplement la commu sous docker, prenez vous des précautions de votre côté ? Quelle est votre expérience ?
Merci à tous !!
PS : en attendant j’attends avant de lancer le nouveau patch de sécurité de mon NAS !!
tldr;
pas possible avec l’image officielle jeedom. c’est la roulette russe. pas de pid 1 géré, pas de process reaper.
La version longue:
L’image officielle est lancé par un script sans aucune gestion particulière lié au PID 1. Le « reaping » de process et la propagation des signaux servent a conduire un arret propre du conteneur. Dans le conteneur jeedom, lors de l’arret demandée du conteneur, le script init reçoit un sigterm mais ne le propage pas aux process démarrés par un service start ou servicectl start. Apres un timeout, le démon docker tue le conteneur, qui abouti parfois a la corruption de la bdd. la doc en anglais ci dessous explique le fonctionnement et l’interet du PID 1.
Il existe plusieurs solutions:
réparer la bdd en montant le volume /ou le volume monté, sur une image mariadb officielle, paramétrer pour démarrer en mode --tc-heuristic-recover=commit ou rollback. puis relancer jeedom. C’est a refaire en cas de pb.
utiliser une bdd externe au conteneur jeedom, il me semble qu’il en possible de le faire. en plus d’etre une bonne pratique, cela fiabilise le systeme. tag: 4.4-http-bookworm
non testé, le script init contient la fonction docker_stop qui devrait être appelée en cas d’arrêt, mais le trap n’est que sur le 15. Il est sans doute possible de faire un docker compose exec jeedom bash -c ‹ source /init.sh; docker_stop ›
cela pourrait possiblement arrêter correctement un conteneur exécutant jeedom et la bdd.
Euhhh OK, faudra que j’y passe du temps pour comprendre…
Après arret de tous mes docker (incluant Jeedom) depuis portaineer,
Puis mise à jour du NAS…
Redémarrage du NAS…
Je redémarre Jeedom et …
Je vais voir les log du docker :
Add trap docker_stop
.
Starting Apache httpd web server: apache2AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 192.168.0.242. Set the 'ServerName' directive globally to suppress this message
… J’en ai marre !!
---- Edit--------
J’ai rien dit, je m’apprêtais à redémarrer le docker et mon jeedom est revenu à la vie
Je crois que ça va rester stressant mais je continuerai au moins à fermer mes dockers pour faire mes mises à jour !
Après lecture de tes propositions :
le premier point je ne suis pas assez calé pour comprendre ce que ça implique ou permet
Le 2nd, oui j’ai compris que ce serait une bonne pratique et en debian 12 ( ce que je suis), ça va devenir sans doute la base un jour. En revanche je ne sais aps en quoi mettre la BDD dans un docker à part permet de la sauver de toute corruption en cas d’arrêt brutal de son docker…
Et le 3ème bah pareil je suis pas calé mais je comprends que tu suggère un moyen de demander à Jeedom de s’arrêter lui et ses services proprement avant d’arrêter le docker ? Si c’est le cas ça vaudrait le coup de tester et de demander à l’équipe Jeedom d’implémenter ça derrière le bouton éteindre en cas de détection d’install sur docker non ?
Le redémarrage du conteneur Jeedom est très long.
Il faut bien 5 minutes. Ce qui peut être considéré comme long de nos jours.
Tu peux voir les phases de démarrage dans l’onglet statistiques et Processus en dessous des graphiques
