fhem-docker Image 4.0.0 (Tester gesucht)

Begonnen von Sidey, 02 März 2024, 11:35:13

Vorheriges Thema - Nächstes Thema

erwin

OK, danke, noch ein volume od. file mounten, die ursprüngliche Frage war aber:
könnte man nicht ein start-beforexxx.sh aus dem sowieso gemounteten /opt/fhem/ directory im standard dockerfile aufrufen?wobei start-beforexxx.sh für die pre-init u. pre-start.sh files steht.
l.g. und danke erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

kadettilac89

Zitat von: erwin am 29 April 2024, 14:22:06OK, danke, noch ein volume od. file mounten, die ursprüngliche Frage war aber:
könnte man nicht ein start-beforexxx.sh aus dem sowieso gemounteten /opt/fhem/ directory im standard dockerfile aufrufen?wobei start-beforexxx.sh für die pre-init u. pre-start.sh files steht.
l.g. und danke erwin

Ich verstehe nicht warum die nicht die bereits bestehenden Absprungpunkte nutzen willst. Das ist ein einziger Mount. Das Image schreibt beim erstellen erst /opt/fhem. Das ist der Ordner der auch in Docker-compose als bind oder mount verwendet wird. Wie willst du überwschreiben und Berechtigungen sicherstellen wenn du schon Scripte ausführen kannst bevor eben dieser Ordner bereit gestellt wird und geladen wird?

Die gegebenen Scripte in einem eigenen Ordner bieten alle Möglichkeiten. Wenn du Sidey zusätzliche, redundante, Skripte einbauen will - gerne, überzeuge ihn. Ich möchte aber Rückwärtskompatibilität und die bestehende Pfade behalten.


kadettilac89

Zitat von: erwin am 29 April 2024, 14:22:06könnte man nicht ein start-beforexxx.sh aus dem sowieso gemounteten /opt/fhem/ directory im standard dockerfile aufrufen?

Ich weiß zwar nicht welchen Vorteil du dir erhoffst. Technisch gesehen kannst du in docker-compose entrypoint mit deinem eigenen Script überschbeiben. Dann musst du halt das bestehende Script "entry.sh" mit deinem eigenen ersetzen. Damit kannst du alles selber steuern. Dann musst du kein zusätzliches Verzeichnis mounten.

Sidey

Zitat von: kadettilac89 am 29 April 2024, 10:34:35Bietet das threaded Perl irgend welche Vorteile? Was Threads sind weiß ich, mir gehts um die Motivation ein solches Image zu bauen.

Wenn man es nicht unbedingt braucht, dann sollte man nicht die threaded Version von Perl verwenden.
Die Motivation ist, dass das 00_SONOS Modul funktioniert, da es threaded entwickelt wurde. Soweit ich weiss, ist es das einzigste Modul was dies benötigt.

Am besten ist es sicherlich, dann in diesem FHEM Container nur das Sonos Modul zu laden und eine zweite FHEM Instanz per FHEM2FHEM anzubinden, da man alle Nachteile des threaded perl erhält.

Hier noch die Details zu dem SONOS Modul ein paar Seiten weiter vorne. :)
https://forum.fhem.de/index.php?topic=137309.msg1306442#msg1306442

Zitat von: kadettilac89 am 29 April 2024, 10:34:35Ich habe mit Beta9 das threaded mal genutzt und festgestellt, dass damit der Healthcheck auf unhealthy geht obwohl Fhem problemlos arbeitet und von außen erreichbar ist.

Ja, das Problem haben wir schon mal mit dem HMCCU Modul glaube ich identifiziert. Das liegt aber eher weniger am Container, als daran wie die Module entwickelt wurden, denn wenn der Healthcheck nicht geht, dann gibt eine der FHEMWEB Instanzen keine Antwort.


Zitat von: erwin am 29 April 2024, 14:22:06könnte man nicht ein start-beforexxx.sh aus dem sowieso gemounteten /opt/fhem/ directory im standard dockerfile aufrufen?

Könnte ja, aber ich werde es nicht einbauen.

Schon die vorhandenen pre-init scripte sind ein antipattern. Irgendwann in naher Zukunft wird im Log erscheinen, dass die Nutzung nur noch kurze Zeit unterstützt ist.
Wer jetzt neu anfängt, dem kann ich nur dringend raten, die Standard Docker Mechanismen zu verwenden. Ihr tut euch einen Gefallen, auch wenn ihr es heute noch nicht wisst.
Wer weiss was er tut, der kann ein eigenes entryscript hinterlegen, jedem der nicht weiss was er da tut, der sollte das Image so verwenden wie es bereitgestellt wird und auch Abstand von den Anleitungen nehmen.

Oft gibt es bessere Alternativen, als zur Laufzeit in einem Container etwas nach zu installieren. In der Regel, findet sich für jedes Problem ein eigenes Image, welches genau dafür gemacht ist.
Eigentlich fällt mir überhaupt keine Notwendigkeit ein, unbedingt was in einem Container zu installieren. Maximal vielleicht, wenn ich was temporär debuggen muss, aber genau danach lade ich mein Image wieder und hab ne saubere Sache.


Grüße Sidey

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

kadettilac89

Sidey, danke für die Antwort auf meine Frage zu Threaded

erwin

Danke Sidey,
deine Erklärung kingt logisch, ich bin im Docker environment nicht firm, daher sind solche statements: ... antipattern, in Zukunft...
sehr hilfreich!
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

kadettilac89

Zitat von: Sidey am 29 April 2024, 21:54:38Ja, das Problem haben wir schon mal mit dem HMCCU Modul glaube ich identifiziert. Das liegt aber eher weniger am Container, als daran wie die Module entwickelt wurden, denn wenn der Healthcheck nicht geht, dann gibt eine der FHEMWEB Instanzen keine Antwort.


Bei mir ist kein HMCCU aktiv. Ich habe mir den Code angesehen. Vor dem Trap wird schon mit "exit 1" das ganze Bash Script verlassen, ein gesetztes PIDFILE wird nie wieder gelöscht (warum auch immer es noch aktiv ist). Die trap-Funktion wird nicht erreicht. Ich vermute du oder der Author wollte nur den Exit Code auf 1 setzen um dann im Trap darauf zu reagieren. Damit das funktioniert muss das Exit-Statement aber in Klammern.

Diese Korrektur meine ich.

#====================================================================================================================-
#--- Main script -----------------------------------------------------------------------------------------------------

[ -e $PID_FILE ] && { echo "Instance already running, aborting another one" ; (exit 1); } # run before installing traphandler!
trap trapExitHandler SIGTERM EXIT

Sidey

Zitat von: kadettilac89 am 01 Mai 2024, 11:44:24
Zitat von: Sidey am 29 April 2024, 21:54:38Ja, das Problem haben wir schon mal mit dem HMCCU Modul glaube ich identifiziert. Das liegt aber eher weniger am Container, als daran wie die Module entwickelt wurden, denn wenn der Healthcheck nicht geht, dann gibt eine der FHEMWEB Instanzen keine Antwort.


Bei mir ist kein HMCCU aktiv. Ich habe mir den Code angesehen. Vor dem Trap wird schon mit "exit 1" das ganze Bash Script verlassen, ein gesetztes PIDFILE wird nie wieder gelöscht (warum auch immer es noch aktiv ist). Die trap-Funktion wird nicht erreicht. Ich vermute du oder der Author wollte nur den Exit Code auf 1 setzen um dann im Trap darauf zu reagieren. Damit das funktioniert muss das Exit-Statement aber in Klammern.

Hmm, ich denke der Author ( ich bin es nicht ) wollte das Script beenden, wenn schon ein Prozess läuft.

Wieso sollte es helfen, in einer subshell einen Exit Status von 1 zu setzen?
Ich vermute auch, dass das Pidfile nur von dem Prozess gelöscht werden soll, der es gestartet hat.

Ist es denn so, dass ein Pidfile da liegt obwohl der Prozess beendet wurde?

Viel Grüße
Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

kadettilac89

Zitat von: Sidey am 01 Mai 2024, 19:51:45Wieso sollte es helfen, in einer subshell einen Exit Status von 1 zu setzen?
Ich vermute auch, dass das Pidfile nur von dem Prozess gelöscht werden soll, der es gestartet hat.

Ist es denn so, dass ein Pidfile da liegt obwohl der Prozess beendet wurde?

Viel Grüße
Sidey

Ich kann auch nur vermuten was gewollt war. "Instance already running, aborting another one" besagt dass der von früher noch laufende Prozess gestoppt werden sollte. " run before installing traphandler!" vermutlich damit der Exitcode schon 1 ist bevor der trap registriert wird.

Bei mir was das PIDFILE über einen Tag alt. Als ich es manuell gelöscht hatte war der Container wieder healthy.

Vom Ablauf wäre es sinnvoll den trap zu Beginn der Verarbeitung zu registieren und dann erst die Checks auszuführen. Aber dagegen sprach irgendwas, warum sonst der Kommentar. Oder der Code hat sich geändert und der Kommentar war für was anderes gedacht.

Sidey

Zitat von: kadettilac89 am 01 Mai 2024, 20:22:52Ich kann auch nur vermuten was gewollt war. "Instance already running, aborting another one" besagt dass der von früher noch laufende Prozess gestoppt werden sollte.
Nein, sehe ich nicht so. Es soll kein weiterer gestartet werden, wenn bereits einer läuft.
Daher auch das exit vor dem traphandler und das weil, ein rm auf das lockfile eingerichtet wurde.


Ich habe mich jetzt ein wenig belesen und vermutlich ist es eine race condition, da das pidfile handling nicht atomar genug realisiert wurde.

Ich habe mich dazu entschieden, eine verlässlichere Methode mittels flock zu implementieren:
https://github.com/fhem/fhem-docker/pull/231

Ich denke morgen gibt es dann auch ein Image mit dieser Anpassung.


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Sidey

Das Image mit der Anpassung beim health check kann unter folgendem Tag geladen werden:

docker pull ghcr.io/fhem/fhem-docker:dev-threaded-bullseye
docker pull ghcr.io/fhem/fhem-docker:dev-bullseye
Viele Grüße
Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

rob

Hallo Sidey.

Du schreibst:
Zitat von: Sidey am 29 April 2024, 21:54:38...
Oft gibt es bessere Alternativen, als zur Laufzeit in einem Container etwas nach zu installieren. In der Regel, findet sich für jedes Problem ein eigenes Image, welches genau dafür gemacht ist.
Eigentlich fällt mir überhaupt keine Notwendigkeit ein, unbedingt was in einem Container zu installieren
...
Es gibt in FHEM ja ein paar Module, welche best. Perl-Module voraussetzen - bspw. Firmata. Im Standard ist das Perl-Modul "Device::Firmata" nicht im Container drin.
Wäre das nicht eine konkrete Notwendigkeit etwas in den Container zu installieren?

Ja ich hab gelesen, dass das mit compose via passendem YAML-File auch geht. Tausche ich dann nicht Antipattern gegen Antipattern? Insbes. weil ich weitere Software installieren muss, nur um den compose-Weg anwenden zu können. Beim Weg via Entry m.E. ähnlich, weil fehleranfällig.

Waren die Parameter und Init-Scripte kein etablierter Weg? Gab es damit viele Probleme?

Vielen Dank und beste Grüße
rob

Sidey

Zitat von: rob am 07 Juni 2024, 16:12:31Hallo Sidey.

Es gibt in FHEM ja ein paar Module, welche best. Perl-Module voraussetzen - bspw. Firmata. Im Standard ist das Perl-Modul "Device::Firmata" nicht im Container drin.

Wäre das nicht eine konkrete Notwendigkeit etwas in den Container zu installieren?

Nein, wenn es fehlt, dann muss es in das Image und nicht in den Container ergänzt werden.
Ich habe mal nachgesehen, aktuell wird es nicht mit eingebaut.
Ich filtere es aber auch nicht explizit heraus.

Was ich für ARM herausfiltere ist Device::Firmata::Constants, weil das irgendwie nicht auf diesen Platformen installiert werden konnte.

Welches Modul braucht denn Device::Firmata ?


Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

rob

Hallo Sidey.

Vielen Dank für Deine flinke Rückmeldung  :)

Zitat von: Sidey am 07 Juni 2024, 19:10:05...
Welches Modul braucht denn Device::Firmata ?
Das Firmata-Modul, welches die Basis ist für eine Reihe darauf aufsetzender Module (https://fhem.de/commandref.html#FRM).

Ja, ich stimme dir zu: das im Image zu haben wäre für meinen Anwendungsfall ideal. Jemand anderem der FRM nicht nutzt, dürfte das Modul hingegen egal/ unnütz sein.
Ich fürchte, wenn Du fragliche Module ins Image aufnehmen würdest, kämen ggf. so einige zusammen. So benötigt bspw. DbLog versch. weitere Module - je nachdem welches Datenbank-Backend verwendet wird. Da hast womöglich nicht viel Freude dabei  ;)

Firmata ist in meinem Fall nicht alles. Ich nutze auch Text2Speech und benötige dafür u.a. "libsox-fmt-all".
Also werde ich wohl entweder doch auf compose umsatteln oder einfach mein eigenes Image builden, das Dein offizielles FHEM v4 als Basis nimmt. Mal schauen, bin noch unentschlossen  :)

Viele Grüße
rob

 

Sidey

Zitat von: rob am 07 Juni 2024, 22:37:52Das Firmata-Modul, welches die Basis ist für eine Reihe darauf aufsetzender Module (https://fhem.de/commandref.html#FRM).

Ja, ich stimme dir zu: das im Image zu haben wäre für meinen Anwendungsfall ideal. Jemand anderem der FRM nicht nutzt, dürfte das Modul hingegen egal/ unnütz sein.

Alles was SVN Module benötigen soll im Image enthalten sein.
Ich hab auch identifiziert, wieso es nicht enthalten ist. Ich werde mich um die Behebung kümmern.


Zitat von: rob am 07 Juni 2024, 22:37:52Firmata ist in meinem Fall nicht alles. Ich nutze auch Text2Speech und benötige dafür u.a. "libsox-fmt-all".

Kannst Du mir sagen, welches Modul dieses Debian Package benötigt?


Grüße Sidey

Edit:

libsox-fmt-all ist schon enthalten.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker