FHEM-Neustart in einem Docker-Container

[FunkOdyssey]

War Titel: FHEM-Docker mit supervisord vielleicht doch besser?

Neuer Erkenntnisse nach dem Erstellen des Threads. Bitte diesen Post besser ignorieren. :-) Aufklärung folgt weiter unten.


Oje, ich habe monatelang darüber geflucht, dass viele Docker-FHEM-Projekte supervisord nutzen, um FHEM als Container laufen zu lassen. Diverse Diskussionen habe ich geführt, da ich den Unsinn nicht verstanden habe.
Aber ich stelle bei mir immer wieder ein Problem fest, welches daher kommt, dass ich FHEM wie folgt starte:

Code: [Auswählen]

#!/bin/bash

set -e

cd /opt/fhem

if ! grep -q "attr global nofork 1" "fhem.cfg"; then
   echo Setze nofork Attribut
   echo Kopiere fhem.cfg zu fhem.cfg.bak
   cp fhem.cfg fhem.cfg.bak
   sed -i /nofork/d fhem.cfg
   echo attr global nofork 1 >> fhem.cfg
   echo Fertig.
fi

echo "Starte FHEM"
perl fhem.pl fhem.cfg
Und zwar habe ich nach dem UPDATE das Problem, dass teilweise mehrere Tage des FHEM-State-Files vermisse.
Eigentlich habe ich eine Art Heartbeat, welches im 5-Minuten-Takt folgendes macht:

Code: [Auswählen]

{WriteStatefile}
Doch heute morgen wurde ich wieder böse überrascht, als ich nach dem FHEM-Update ein "shutdown restart" durchgeführt habe und ich plötzlich ein FHEM-State-File vom 14.04.2018 (letzter Neustart) hatte. Ich erkenne das an diversen ReadingsHistory-Konfigurationen.

In meiner "docker-compose.yml" habe ich für den FHEM-Container "restart: unless-stopped" festgelegt. Jeder andere Wert dürfte das Problem aber nicht verringern.

Ich glaube, dass ich durch das "shutdown restart" quasi ein STOP erzeuge und Docker daraufhin den Container neu durchstartet. Es handelt sich also gar nicht um einen sauberen FHEM-Neustart sondern quasi die harte Methode.

Das ist ärgerlich, da FHEM dann einige Dinge nicht mehr zu Ende bringen kann. Wie bspw. das State-File zu Ende schreiben.

Oder habe ich ein Brett vor dem Kopf und sehe nur die Lösung nicht?

Ärgerlich: Ich will kein supervisord bzw. auch kein BaseImage (oder vergleichbares) nutzen.

[Darrol]

Hi FunkOdyssee,

wenn ich es mit Docker richtig verstanden habe ist es einem Container normalerweise ziemlich egal welche Prozesse darin laufen/neustarten/stoppen etc..

Die Regel  "restart: unless-stopped"  sollte demnach allenfalls dann greifen wenn der Container vollständig crasht oder wenn irgendetwas von außen den Stop verursacht hat(z. B. ein Stromausfall) .
Ich würde also zunächst mal an der Stelle ansetzen und sehen ob der Container beim shutdown restart vielleicht komplett abstürzt.

[FunkOdyssey]

Oh, das wird jetzt kompliziert. Ich habe vorsichtshalber auch den Threadtitel geändert, um nicht auf die falsche Fährte zu locken.

Ich habe mittlerweile neue Erkenntnisse und es hat wohl gar nichts mit dem statefile zu tun.
Ich hatte ja beiläufig erwähnt, dass ich mich an einer readingsHistory orientiere. Nun ja. Es sieht so aus, als würde ich mit FHEM@Docker nur den Zustand der Datei "/log/readingsHistorys.dd.save" verlieren.
Aus diesem Grund habe ich im passenden Forum folgenden Thread gestartet: Wann wird eine readingsHistory gespeichert?

- Führe ich ein "shutdown restart" durch, so bleibt das statefile erhalten. Es ist kein zusätzliches manuelles "Save" erforderlich.
- Bei meinem obigen Startskript wird der Container tatsächlich beendet und neu gestartet, da der Hauptprozess halt "kurz" beendet wird. Hätte ich kein "restart: unless-stopped", so würde der Container angehalten bleiben. Dies habe ich ausprobiert.
- Aber ich  habe eine wunderbare FHEM-Dockerfile-Variante gefunden, die dies abfängt und entsprechend berücksichtigt. Ich kann nur Werbung machen für das folgende FHEM/Docker-Projekt: https://github.com/JoschaMiddendorf/fhem-docker
Einfach mal einen Blick auf die StartAndInitialize.sh werfen und stauen. Tatsächlich wird überwacht, ob FHEM nur kurz weg ist und es wird ein Countdown gestartet. Der Container läuft weiter. Praktisch.
- Dies war nun also meine Hoffnung, dass der Zustand des FHEMs überlebt. Aber die readingsHistory hat nach nem "shutdown restart" wieder Lücken. Und zwar entweder vom letzten Neustart oder basierend auf dem letzten "Save".
- So hätte supervisord auch überhaupt nicht geholfen. Da bin ich ja froh, den ich mag den Ansatz halt überhaupt nicht. Die Lösung von Joscha Middendorf ist weitaus eleganter.

Ein Auszug aus dem Docker-Log:

Code: [Auswählen]

2018.04.17 14:04:32.960 0: Server shutdown
FHEM process terminated unexpectedly, waiting for 10 seconds before stopping container...
waiting - 10
waiting - 9
waiting - 8
waiting - 7
waiting - 6
waiting - 5
waiting - 4
FHEM process reappeared, kept container alive!
FHEM is up and running again:

Fazit:
Ich habe nun eine saubere Variante, die auf unkontrollierte SIGTERM & Co. reagiert. FHEM wird stets sauber heruntergefahren.

Aber:
Die readingsHistory sind nach dem Neustart veraltet. Dies verfolge ich im verlinkten Thread nun weiter.

[Diggewuff]

Ein docker Container steigt immer dann aus wenn der Hauptprozess aus dem Docker run Befehl pid 1 aussteigt. Das heist wenn FHEM der Hauptprozess ist, auch bei einem shutdown restart.
Das hat mich gestört und supervisor war für mich keine Option. Daher habe ich diesen Container gebaut. @FunkOdyssey, danke für die Werbung.
Mein Interesse ist es den Container immer weiter zu verbessern und auf aktuellem Stand zu halten. Daher freue mich über jeden der den Container nutz und seine Erfahrungen teilt. Gerne direkt in github.
Der Container läuft unter jedem dicker fähigen System und konfiguriert sich vollständig selbst.
Verfügbar als automated build auf DockerHub
https://hub.docker.com/r/diggewuff/fhem-docker/
oder zum mitwirken auf GitHub
https://github.com/JoschaMiddendorf/fhem-docker