fhem-docker Image 4.0.0 (Tester gesucht)

[erwin]

OK, danke, noch ein volume od. file mounten, die ursprüngliche Frage war aber:

Code Auswählen Erweitern

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

[kadettilac89]

OK, danke, noch ein volume od. file mounten, die ursprüngliche Frage war aber:

Code Auswählen Erweitern

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]

kö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]

Bietet 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

Ich 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.

Code Auswählen Erweitern

kö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

[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

[kadettilac89]

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.

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.

Code Auswählen Erweitern


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

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


[Sidey]

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.

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

[kadettilac89]

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

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]

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.

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

[Sidey]

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

Code Auswählen Erweitern

docker pull ghcr.io/fhem/fhem-docker:dev-threaded-bullseye

Code Auswählen Erweitern

docker pull ghcr.io/fhem/fhem-docker:dev-bullseye
Viele Grüße
Sidey