Démon NOK avec la version 2022-07-19 01:01:16

Ok, ça roule.
Envoie moi un message quand tu commences, je te dirais si je suis dispo à ce moment là.
Passe bien tous les logs en debug (plugin et brokers),
Si tu es sur Discord on peu peut être voir ça par la bas en partage d’écran aussi.

Hello
Même résultats chez moi depuis la mise à jour passée hier soir.
Je suis dans une configuration similaire Jeedom Docker en 4.2.20.
Petite différence, peut être, mon container tourne en macvlan et mon broker tourne dans un autre container en mode host pour le coup… et donc un port 80 « vampirisé » par le Syno.
Je n’ai rien restauré et tout laissé en l’état pour investiguer.
Je passe mon mosquitto en macvlan ce soir et vous tiens au jus.

Hello,

Merci pour ce retour.
Est ce que tu as essayé d’appliquer le patch plus haut ?

Bad

Pas de problème, c’est normal vu le changelog :raised_hands:

Oui aussi.
Mais loin de moi l’idée de brouiller le fil de @defmy, on a peut être pas la même config, comportement du demon et traces.
C’est la piste du 80 qui m’intrigue.
Je vous fait un retour ici, ou dans un autre fil avec plus de détails, en fonction des résultats au passage du broker dans le macvlan.

Tu aurais le compose pour déployer cette stack ?
Ou un lien vers la procédure que tu as suivi ?
Je veux bien monter un env de mon côté aussi.

Je n’utilise que des run…
J’ai donc pour le moment :

docker run --name=mosquitto \
 --restart=unless-stopped \
 -p 1883:1883 \
 -p 9001:9001 \
 -v /volume1/docker/mosquitto/config/mosquitto.conf:/mosquitto/config/mosquitto.conf \
 -v /volume1/docker/mosquitto/data:/mosquitto/data \
 -v /volume1/docker/mosquitto/log:/mosquitto/log \
 -itd eclipse-mosquitto

Auquel j’ajourterai :

 --net=macvlan0 \
 --ip=IP_MACVLAN_AVAIL \

Sinon pour la création du macvlan, il y a le très bon tuto de @Didier3L :

Bien qu’un /29 va finir par devenir étriqué :sweat_smile:

1 « J'aime »

Ok, merci, c’est surtout Jeedom en Docker que je n’ai jamais fait.
Mon Broker est aussi en Docker :wink:

1 « J'aime »

Je pense qu’on doit avoir le même soucis tu ne brouilles pas le sujet. On a le même comportement bien que l’architecture diffère légèrement.
Moi je suis en bridge, pas de mode host avec jeedom et donc indépendante du système. J’arrive à joindre sans souci Mosquitto qui est dans le même réseau Docker que mon Jeedom.

2 « J'aime »

Sur quelle plateforme es-tu ?

Comme toi sans doute, juste la partie réseau qui doit fonctionner différemment

1 « J'aime »

Config cible atteinte : même résultats.
Au final mon Jeedom tourne sous docker dans un container « dédié » et Mosquitto dans un autre, tous 2 désormais en macvlan.
Mon docker est hébergé sur un DS918+ (paquet officiel) et le macvlan s’est imposé en rainson des limites de Synology sur les ports 80 et 443.
Petite différence, peut être, avec ta config @defmy : j’utilise nginx et letsencrypt via les fonctionnalités natives du NAS.

Sans le patch, sauf erreur, j’avais un daemon is already run qui se promenait en plus de ce qui suit.
Avec le patch suggéré, suppression ou non de /tmp/jeedom/jMQTT/jmqttd.py.pid avant le redemarrage, j’ai dans les logs :

  • jMQTT :
0485|[2022-07-20 23:15:05]INFO : Démarrage du démon jMQTT
0486|[2022-07-20 23:15:05]DEBUG : Nettoyage du Démon
0487|[2022-07-20 23:15:13]INFO : Lancement du démon jMQTT
0488|[2022-07-20 23:15:14]WARNING : Démon [26596:41748] : N'a pas pû être validé
0489|[2022-07-20 23:15:18]DEBUG : Démon [26723:38288] : Impossible d'autoriser la cmd 'hb' avant la commande 'daemonUp': '{"cmd":"hb"}'
0490|[2022-07-20 23:15:23]DEBUG : Nettoyage du Démon
0491|[2022-07-20 23:15:23]ERROR : Impossible de lancer le démon jMQTT, vérifiez le log
0492|[2022-07-20 23:15:28]DEBUG : Démon [31679:44047] : Impossible d'autoriser la cmd 'hb' avant la commande 'daemonUp': '{"cmd":"hb"}'
0493|[2022-07-20 23:15:45]DEBUG : Démon [1955:38279] : Impossible d'autoriser la cmd 'hb' avant la commande 'daemonUp': '{"cmd":"hb"}'
  • jMQTTd :
0436|[2022-07-20 21:15:14,382]INFO Main            MainThread   set_log_level() : New log level set to: DEBUG
0437|[2022-07-20 21:15:14,383]DEBUG Main            MainThread         prepare() : Writing PID 26596 to /tmp/jeedom/jMQTT/jmqttd.py.pid
0438|[2022-07-20 21:15:14,383]INFO Main            MainThread         prepare() : Start jMQTT python daemon
0439|[2022-07-20 21:15:14,383]INFO Main            MainThread         prepare() : Log level  : debug
0440|[2022-07-20 21:15:14,384]INFO Main            MainThread         prepare() : Socket port: 0
0441|[2022-07-20 21:15:14,384]INFO Main            MainThread         prepare() : PID file   : /tmp/jeedom/jMQTT/jmqttd.py.pid
0442|[2022-07-20 21:15:14,384]DEBUG Main            MainThread         prepare() : Apikey    : BeAuCoUpDeCaRaCtErEs
0443|[2022-07-20 21:15:14,384]DEBUG JMsg.Rcv        MainThread  receiver_start() : Start requested
0444|[2022-07-20 21:15:14,385]DEBUG JMsg.Rcv        SockIn            _loopRcv() : Start
0445|[2022-07-20 21:15:14,386]INFO JMsg.Rcv        MainThread  receiver_start() : Started, listening on [127.0.0.1:41748]
0446|[2022-07-20 21:15:14,409]DEBUG JMsg.Snd        MainThread       send_test() : Test successful
0447|[2022-07-20 21:15:14,409]DEBUG JMsg.Snd        MainThread    sender_start() : Start requested
0448|[2022-07-20 21:15:14,410]DEBUG JMsg.Snd        SockOut           _loopSnd() : Start
0449|[2022-07-20 21:15:14,410]INFO JMsg.Snd        MainThread    sender_start() : Started
0450|[2022-07-20 21:15:14,410]DEBUG JMsg.Snd        MainThread      send_async() : Enqued message: {'cmd': 'daemonUp'}
0451|[2022-07-20 21:15:14,410]DEBUG Main            MainThread       open_comm() : Open Comm   : Sent Daemon Up signal to Jeedom
0452|[2022-07-20 21:15:14,510]DEBUG JMsg.Snd        SockOut           _loopSnd() : Sending 1 msgs
0453|[2022-07-20 21:15:14,596]DEBUG JMsg.Snd        SockOut               send() : Sent TO Jeedom: [{'cmd': 'daemonUp'}]
0454|[2022-07-20 21:15:18,612]DEBUG JMsg.Snd        SockOut           _loopSnd() : Sending 1 msgs
0455|[2022-07-20 21:15:18,625]DEBUG JMsg.Snd        SockOut               send() : Sent TO Jeedom: [{'cmd': 'hb'}]
0456|[2022-07-20 21:15:28,358]DEBUG JMsg.Snd        SockOut           _loopSnd() : Sending 1 msgs
0457|[2022-07-20 21:15:28,370]DEBUG JMsg.Snd        SockOut               send() : Sent TO Jeedom: [{'cmd': 'hb'}]
  • jMQTT_mosquitto :
0024|[2022-07-20 23:15:05]INFO : Client MQTT déconnecté du Broker
0025|[2022-07-20 23:15:23]INFO : Client MQTT déconnecté du Broker
  • http.error : nada

Ok, top, je vois où ça coince !
Dans la nouvelle version, le daemon chope un port dynamique pour éviter les collisions de port. Quand il se démarré, il donne à Jeedom le port qu’il utilise au moment du daemon « daemonUp ». Jeedom valide qu’il ne connait pas d’autre daemon en cours et vérifie que le port et le pif correspondent bien à quelle que chose (ouais je sais, c’est overkill, mais c’est safe).

Dans le cas de Docker, Jeedom ne doit pas pouvoir faire cette correspondance (pid/port) et refuse le daemon.

Je vais regarder comment assoupir le système ou le rendre débrayable.

Cet environnement est en prod ou en test ?
Je peux te donner des patch ?

Merci en tout cas,
Bad

1 « J'aime »

Toute à l’heure j’ai déployer cette stack :

version: "3.1"
services:
  jeedom:
    image: jeedom/jeedom:alpha
    container_name: jeedom
    privileged: true
    volumes:
      - data:/var/www/html
      - db:/var/lib/mysql
    ports:
      - 9080:80
    restart: unless-stopped
volumes:
  data:
  db:

Conf Market, install jMQTT avec Mosquitto en local, tout à bien démarré…

Tu run en privileged ou pas ?

J’avoue que je n’ai pas trop envie de faire l’install en macvlan sur le Syno, la conf réseau m’a l’air étrange (pourquoi le macvlan est dans le même sous réseau que le lan ?).

Bad

J’utilise aussi nginx et letencrypt mais sur un Raspberry. Il est en écoute sur 80/443 et fait proxypass sur jeedom donc quelque soit le port que tu utilises pour jeedom, il y a pas de problème d’où peu d’intérêt de passer par le macvlan.

J’utilise aussi cette conf, par contre pas de privileged à true et mosquitto sur un autre docker. Ça marche chez toi du coup ?

Je try demain de relancer la stack sans privileged, je pense que c’est le pb.

Hello,

Je suis passé en Docker hier soir, et il y a un bien un impact lié au privilège.
La doc officielle indique de se mettre en --privileged
C’était un peu trop permissif à mon gout.
J’ai donc cherché la permission nécessaire à jMQTT.
Il s’agit de --cap-add=SYS_PTRACE
En rajoutant cette capabilities, ca fonctionne :smiley:

2 « J'aime »

Ok, merci @Domochip

Je confirme que sans privileged: true le compose ci-dessus ne permets pas le lancement de jMQTT.
Par contre avec celui-ci (qui revient à ajouter --cap-add=SYS_PTRACE), jMQTT est OK :

version: "3.1"
services:
  jeedom:
    image: jeedom/jeedom:alpha
    container_name: jeedom
    cap_add:
      - SYS_PTRACE
    volumes:
      - data:/var/www/html
      - db:/var/lib/mysql
    ports:
      - 9080:80
    restart: unless-stopped
volumes:
  data:
  db:

Pareil, c’était beaucoup trop privileged à true, surtout que j’ai que des satellites, donc chez moi jeedom ne sert qu’interface de gestion.

En tout cas ça marche avec cette capacité, merci pour ta contribution.

Hello

Dsl pour hier soir, j’avais les yeux qui se croisaient :dizzy_face:

Entièrement d’accord : aucun container en privileged

En tout cas, bien vu @Domochip ! :clap:
Tout fonctionne aussi de mon coté, avec ou sans le patch.

Merci à vous pour la reprise et l’incoryable upgrade de ce plugin, ainsi que votre support ultra réactif :star_struck:

1 « J'aime »