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