[HowTo] /dev/watchdog auf BBB oder RasPi für Neustart im Fehlerfall nutzen

Begonnen von betateilchen, 21 Februar 2014, 11:48:12

Vorheriges Thema - Nächstes Thema

betateilchen

Sowohl der Beaglebone Black als auch der RaspberryPi verfügen über einen hardwareseitig eingebauten watchdog, der das gesamte System im Fehlerfall automatisch neu booten kann. Die Nutzung ist recht einfach, ich will das hier kurz beschreiben.

Installation der Kernelmodule für den Watchdog:

1. Für den Beaglebone Black unter Debian i.d.R. nicht notwendig, da bereits installiert.

2. Für den Raspberry Pi auf der Systemkonsole folgende zwei Befehle ausführen:



$ sudo modprobe bcm2708_wdog
$ echo "bcm2708_wdog" | sudo tee -a /etc/modules



Das watchdog device findet man als /dev/watchdog das kann man mit



$ ls -al /dev/watchdog



kontrollieren. Das watchdog device funktioniert in der Art, dass es nach dem erstmaligen Öffnen und Beschreiben alle 60 Sekunden beschrieben werden möchte. Bleibt dieses Beschreiben für 60 Sekunden aus, wird ein Reboot ausgelöst.

Wer das testen möchte:



$ sudo cat > /dev/watchdog
   (damit wird das Device geöffnet.

Jetzt einmal <enter> drücken
   (damit wird das Device erstmalig beschrieben)

nun warten und auf die Uhr schauen :)
   nach 60 Sekunden sollte der Neustart erfolgen.




Installation des Watchdog Dämon

Der Watchdog Dämon übernimmt die Funktion des regelmäßigen Beschreibens von /dev/watchdog, er tut dies anhand Kriterien, die man in einer conf-Datei vorgibt.



$ sudo apt-get install watchdog



Damit wird der Dämon installiert, aber noch nicht gestartet.

Denn nun müssen wir dem Dämon noch eine Konfiguration verpassen, damit er weiss, wie er das laufende System überwachen soll.



$ sudo nano /etc/watchdog.conf

In dieser Datei müssen zumindest die beiden folgenden Zeilen aktiviert werden, dazu würd das # am Anfang der Zeile entfernt.

watchdog-device        = /dev/watchdog
max-load-1             = 24

Der Rest der Datei bleibt vorerst unangetastet.



Bei mir habe ich die Überwachung so gelöst, dass ich watchdog auf eine Datei prüfen lasse, von der ich genau weiss, dass fhem sie (bei mir) regelmäßig beschreibt. Per at-Definition werden bei mir sämtliche states aller Devices alle 30 Minuten gesichert. Ich habe also eine Datei fhem.save in /opt/fhem/log die sich alle halbe Stunde ändert. Perfektes Futter für den watchdog :)

In die watchdog.conf kommen also noch diese beiden Zeilen:



file = /opt/fhem/log/fhem.save
change = 2000



Also wenn sich die Datei 2000 Sekunden lang nicht ändert, geht der watchdog Dämon davon aus, dass irgendwas nicht stimmt und führt den Neustart durch.


Nun müssen wir den Watchdog noch starten:



$ /etc/init.d/watchdog start



Die Einbindung in die Runlevel wird bereits bei der Installation durchgeführt, es wird aber bei der Installation kein Starten durchgeführt.




Es gibt /dev/watchdog auch auf Fritzboxen. Ich weiß allerdings nicht, ob es den Dämon dort auch gibt bzw. ob er nachträglich installiert werden kann.

Wer genau wissen möchte, was der Dämon alles überwachen kann, sei auf die manpage von watchdog.conf verwiesen.

http://linux.die.net/man/5/watchdog.conf

Warnung! Warnung! Warnung! Warnung! Warnung!

Ich warne ausdrücklich vor der Nutzung der Netzwerktests (interface oder ping) auf Einplatinencomputern! Damit hat man sich schneller ausgesperrt, als man denkt, denn oft schlägt der watchdog schneller zu als die Zeit, die das Netzwerkdevice braucht, um nach einem Neustart betriebsbereit zu sein. Vor allen Dingen, wenn es sich um WLAN Sticks oder sonstige per USB angeschlossene Komponenten handelt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Luigi

Ich hab ein Problem mit meinem BBB, er bleibt nach einem Neustart hängen, alle blauen LEDs leuchten. Erst wenn ich ihn vom Strom trenne und wieder anschließe startet er neu.

Was könnte das sein?

Gruß
Luigi

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Billy

FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Luigi

Wird vom internen Flash gestartet, Stromversorgung mit 2A Netzteil

Gesendet von meinem GT-I9505G mit Tapatalk 2


Billy

ZitatStromversorgung mit 2A Netzteil

Über miniusb oder 5v power jack?
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*


Billy

ZitatÜber MiniUSB!
Das dürfte das Problem sein! Dafür gibts genügend Beispiele im Netz.

Geh mal über den 5V Power jack und schau was passiert!
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Luigi

Hab nochmals nachgeschaut, die Stromversorgung erfolgt über den 5V Power jack.

betateilchen

Du bootest von Flash, ok. Trotzdem die Frage: Steckt zu diesem Zeitpunkt eine microSD Karte im BBB?

Die Spannungsversorgung lassen wir mal aussen vor.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Luigi


Loredo

Super spitze, genau das Thema schwirrte mir heute im Kopf herum und schwupp, siehe da...  :D
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Brockmann

Kleine Ergänzung:
Habe versucht, anhand des Howtos auf meinem Raspi mit aktuellem Raspian watchdog zu installieren, was leider auf Anhieb nicht klappte:
insserv: There is a loop between service watchdog and mathkernel if stopped

Deshalb habe ich mit
sudo apt-get remove wolfram-engine
den mathkernel deinstalliert. Danach ließ sich watchdog wie beschrieben installieren.

Nur falls jemand auf dasselbe Hindernis stößt...

betateilchen

Am Anfang der /etc/init.d/mathkernel folgende Zeilen einfügen:



### BEGIN INIT INFO
# Provides:          mathkernel
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: mathkernel
### END INIT INFO



dann sollte sich der watchdog auch in Kombination mit der wolfram-engine installieren lassen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

nocomment

Cooles HowTo!

Wie kann ich FHEM sagen das es alle 30 Minuten den aktuellen Status in die fhem.save schreibt?

Gruß,
Patrick

Loredo


# save current state every 30 minutes
define at_FHEM.save at +*00:30:00 save
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

nocomment

Okay, das ist einfach.

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

Danke Loredo

betateilchen

Zitat von: Loredo am 05 Mai 2014, 01:25:58
# 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}
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hexenmeister

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

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

betateilchen

#20
Zitat von: hexenmeister am 05 Mai 2014, 18:43:57
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hexenmeister

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)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

betateilchen

#22
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hexenmeister

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*
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Harald

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:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus