Autor Thema: [HowTo] /dev/watchdog auf BBB oder RasPi für Neustart im Fehlerfall nutzen  (Gelesen 40990 mal)

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2823
  • ~ Challenging Innovation ~

# save current state every 30 minutes
define at_FHEM.save at +*00:30:00 save
FHEM-Module: ENIGMA2, GEOFANCY, ONKYO_AVR, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, powerMap, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM 5.9dev auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs
ONKYO TX-NR626, Philips 55" PFL8008S, Sonos 1xS1, 1xS3, 2xS5

Offline nocomment

  • Full Member
  • ***
  • Beiträge: 123
Okay, das ist einfach.

Sorry für die dumme Frage,
wusste den Befehl nicht.

Danke Loredo

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13674
  • Das "S" in "IoT" steht für "Security"
# save current state every 30 minutes
define at_FHEM.save at +*00:30:00 save

Damit sicherst Du aber nicht nur das statefile, sondern die gesamte Konfiguration. Wenn man nur das Statefile sichern will, kann man das so machen:

define at_FHEM.save at +*00:30:00 {WriteStatefile}
-----------------------
Nächster Hamburg-Stammtisch: 15.12.2017

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13674
  • Das "S" in "IoT" steht für "Security"
Noch ein wichtiger Hinweis zum Triggern auf fhem.save:

Das funktioniert nicht, wenn man für die fhem-Konfiguration mit configDB arbeitet!

In dem Fall gibt es keine fhem.save mehr, weil die kompletten states in die Datenbank geschrieben werden. Bei mir gibt es deshalb eine at-Definition auf eine (leere) Datei /opt/fhem/log/fhem.heartbeat deren Zeitstempel einmal pro Minute per at durch touch geändert wird:

define heartbeat at +*00:01:00 {qx(touch /opt/fhem/log/fhem.heartbeat)}
In der watchdog.conf prüfe ich mit einem Intervall von 150 Sekunden auf diese Datei geprüft.
-----------------------
Nächster Hamburg-Stammtisch: 15.12.2017

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3586
    • tech_LogBuch
Ist das nicht ein wenig 'overkill', das gesamte System zu restarten, nur weil FHEM nicht (mehr) läuft?
Das bedeuten ja auch, dass FHEM auch nicht problemlos und ohne 'Vorarbeit' beenden werden kann.

Aus meiner Sicht wäre ein zweistufiges Verfahren besser geeignet.
1. Ein Script, das eine FHEM.heartbeat Datei überwacht und ggf. FHEM-Server neu startet (und bei Bedarf auch 'hart' abschießt).
2. Das hier, startet den Raspberry neu, überwacht eine Datei, die per CRON-Job aktualisiert wird.

Zu 1. wurde etwas bei der Diskussion eines anderen Thema schon mal besprochen: http://forum.fhem.de/index.php/topic,17221.msg112667.html#msg112667

Cubietruck, RPI3, HM, EnOcean, 1wire, Firmata, MySensors, ESP8266, ESPEasy, MQTT, NodeRED, Alexa, Telegram

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13674
  • Das "S" in "IoT" steht für "Security"
Das bedeuten ja auch, dass FHEM auch nicht problemlos und ohne 'Vorarbeit' beenden werden kann.

Wieso nicht? Du hast 150 Sekunden Zeit.  Und NEIN - es ist kein Overkill, sondern beruht auf Erfahrungen aus der Praxis.
Es steht Dir natürlich frei, den watchdog so zu konfigurieren, dass er nicht den ganzen Raspberry neustartet, sondern nur fhem selbst. Dein vorgeschlagenes zweistufiges Konzept ist völlig überflüssig, wenn man die von watchdog angebotenen Möglichkeiten einfach nutzt, wie man sie  möchte.

Der hier vorgeschlagene Weg ist auf jeden Fall der absolut zuverlässigste für unbeaufsichtigt laufende fhem Installationen, auf die es auch keinen Zugriff per Fernwartung gibt.
« Letzte Änderung: 27 Oktober 2014, 13:39:13 von betateilchen »
-----------------------
Nächster Hamburg-Stammtisch: 15.12.2017

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3586
    • tech_LogBuch
Ich sehe zwei Arten von Problemen:
FHEM abgestürzt und Linux hängt.
Aus meiner Sicht sind hier auch zwei Lösungen gefragt. Mein Vorschlag hat schon seine Vorteile. Aber lassen wir das...  8)
Cubietruck, RPI3, HM, EnOcean, 1wire, Firmata, MySensors, ESP8266, ESPEasy, MQTT, NodeRED, Alexa, Telegram

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13674
  • Das "S" in "IoT" steht für "Security"
Die Intention dieses Threads war eine Anleitung nach der Art "watchdog für Dummies" - also eine Lösung, die für Anfänger und Anwender mit wenig Hintergrundwissen mit möglichst wenig Aufwand den größtmöglichen Nutzen für diese Zielgruppe schafft. Und das tut sie.

Natürlich gibt es unzählige Möglichkeiten, das Ganze zu verfeinern. Und auch bei mir sieht die watchdog-Konfiguration etwas anders aus als hier dargestellt. Aber wie gesagt: Die Intention für diese Anleitung hier war eine andere. Und jemand wie Du, der durchaus schon die verschiedenen Problemebenen kennt und weiß, wie er damit umzugehen hat, braucht doch diese Anleitung hier sowieso nicht. Also hör doch bitte einfach auf damit, Anfänger zu verunsichern und die Sache zwanghaft schlechtreden zu wollen.
« Letzte Änderung: 09 September 2014, 09:21:05 von betateilchen »
-----------------------
Nächster Hamburg-Stammtisch: 15.12.2017

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3586
    • tech_LogBuch
Tach auch   8)
Ich würde ja gerne mit Dir streiten, habe aber gerade heute leider keine Lust :)

Trotzdem, wo habe ich denn etwas schlecht reden wollen, und dann auch noch zwanghaft? Ganz im Gegenteil, ich finde Deine Anleitung gut und nützlich, vor allem für Anfänger.
Aber Du weiß doch, welche Eigenschaft für einen Anfänger am wichtigsten ist? Aus meiner Sicht ist das der Lernwille, also Wissensdurst. Und den habe ich zu stillen geholfen, indem ich Möglichkeiten zu Verbesserung und Weiterentwicklung aufgezeigt habe. Also hat der geneigte Anfänger gleich zwei Möglichkeiten: so nehmen, wie es angeboten wird, oder die Lösung (und sich selbst) weiter zu entwickeln. Was daran findest Du falsch? Du willst ihn doch ganz bestimmt nicht dieser wertvoller Möglichkeit beraubt sehen?  ;D
Ich hab doch nur nach meinen (bescheidenen) Kräften geholfen, das Wissen in die Welt zu tragen :D

Komm, hör auf ein Angriff dort zu sehen, wo es keiner war. ;)
*handreich*
« Letzte Änderung: 06 Mai 2014, 17:11:07 von hexenmeister »
Cubietruck, RPI3, HM, EnOcean, 1wire, Firmata, MySensors, ESP8266, ESPEasy, MQTT, NodeRED, Alexa, Telegram
Hilfreich Hilfreich x 1 Liste anzeigen

Offline Harald

  • Sr. Member
  • ****
  • Beiträge: 633
Hallo Betateilchen,

vielen Dank für die tolle Anleitung. Danach habe ich problemlos den Wachhund auf dem Pi mit der Abfrage der fhem.heartbeat zum Laufen bekommen  ;D und auch gleich die 1/2 stündige Sicherung der fhem.save aktiviert. Ich hoffe, dass es mir in Zukunft nicht mehr passiert, dass nach einem Absturz des Systems die bis dato ermittelten Messwerte weg sind. Die sollten jetzt einigermaßen akuell in der fhem.save verfügbar sein.

Herzlichen Dank nochmal und viele Grüße

Harald

Router:AVM7490 1&1 FW:FRITZ!OS 06.51 Anbindung:1&1 16/50 Mb/s, WLAN-Repeater 300E OS 6.04
ELV MAX!Cube, 7xThermostat, ECO, Raspberry Pi B mit Wheezy auf Festplatte,
CUL-V3_1.61, JeeLink v3_10.1c, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA
ELV MAX!1.4.5, MAX!Buddy, -Backup, FHEM 5.7 auf RasPi

 

decade-submarginal