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ämonDer 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.
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
startest Du Deinen BBB von microSD oder vom internen Flash?
Und wie wird er mit Strom versorgt?
Wird vom internen Flash gestartet, Stromversorgung mit 2A Netzteil
Gesendet von meinem GT-I9505G mit Tapatalk 2
ZitatStromversorgung mit 2A Netzteil
Über miniusb oder 5v power jack?
Über MiniUSB!
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!
Hab nochmals nachgeschaut, die Stromversorgung erfolgt über den 5V Power jack.
Du bootest von Flash, ok. Trotzdem die Frage: Steckt zu diesem Zeitpunkt eine microSD Karte im BBB?
Die Spannungsversorgung lassen wir mal aussen vor.
Nein, es steckt keine microSD Karte im BBB!
Super spitze, genau das Thema schwirrte mir heute im Kopf herum und schwupp, siehe da... :D
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...
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.
Cooles HowTo!
Wie kann ich FHEM sagen das es alle 30 Minuten den aktuellen Status in die fhem.save schreibt?
Gruß,
Patrick
# save current state every 30 minutes
define at_FHEM.save at +*00:30:00 save
Okay, das ist einfach.
Sorry für die dumme Frage,
wusste den Befehl nicht.
Danke Loredo
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}
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.
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
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.
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)
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.
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*
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