Ist jetzt kein starkes Gegenargument, insb. in deinem Fall nicht.
Mir war nicht bewusst, dass ich Gegenargumente bringen muss. ;-)
Ich kenne diese Probleme nicht, da ich das health-check script nicht erstellt habe.
Es wurde mir von loredo nur so mitgegeben, dass er von nc auf den fhem clientmode umgestellt hatte, da es Probleme gegeben hat.
Wenn Du der Meinung bist, dass nc besser geeignet ist um fhem Daten an der telnet Schnittstelle zu übergeben dann reiche ich gerne eine PR ein, der das umsetzt.
Soll ich deine Empfehlung denn so verstehen, den fhemclientmode nicht zu verwenden und stattdessen immer netcat?
Verstehe ich nicht: wenn einer bereits laeuft, muss healthcheck halt false liefern.
Laut Internet hat docker selbst fuer healthcheck Prozesse einen timeout von 30 Sekunden und versucht es nur 3-mal, beides konfigurierbar.
Was _genau_ ist das Problem? Wohl kaum, dass die ps Ausgabe laenger wird.
Das kann man so machen. Die drei Zeilen Code habe ich ja bereits getestet.
Das löst aber nur, dass keine weitere Aufrufe des fhemclients erfolgen. Den unendlich hängenden Prozess löst das nicht.
Der Timeout von docker beendet den laufenden Prozess ebenfalls nicht, der setzt den laufenden dockerprozess dann lediglich auf "unhealthy".
Damit docker feststellen kann, ob sich etwas am Status verändert, ruft es weiterhin den health-check auf.
Das ist mAn zu lang, und ich wuesste gerne, wo es den Unterschied macht.
Wenn ich ein Timeout einbaue, waere der default bei 4-5 Sekunden.
Ich verstehe das Problem nicht, und ich vermute immer noch, dass die vorgeschlagene Loesung nicht die Richtige ist.
In meinem Beitrag ging es mir darum, aufzuzeigen, dass der fhemclient Mode keinerlei Timeout kennt und quasi bis in das unendliche wartet.
Das beispiel im docker health-check script war nur
ein Beispiel wie sich das auswirkt.
Dass ich dem Aufruf auch eine timeout vorsetzen könnte ist mir durchaus bekannt. Ich bin aber der Meinung, dass der fhemclientmode einen Timeoutparameter vertragen könnten, so wie er in vielen anderen tools auch enthalten ist, die davon abhängig sind, dass eine Gegenstelle reagiert.
Von diesem Timeout würden letztendlich alle profitieren, die diesen clientmode verwenden. Die Lösung, dass jeder der es nutzt sich einen timeout drum herum baut führt doch eher dazu, dass es nicht getan wird, weil da keiner dran denkt und im Normalfall, solange fhem läuft dieser auch nicht benötigt wird.
Eine Timeout aus fhem.pl heraus, hätte halt noch ermöglicht, auf die Ausgabe zu reagieren. Das quasi nachzubauen ist aus meiner Sicht unfug.
Grüße Sidey
Thema: fhem.pl client mode default timeout (Gelesen 438 mal)