Embedded Files
Ein Watchdog passt auf, daß sich die Programme nicht vertrödeln oder verlaufen. Und wenn sie sich verlaufen haben, soll er bellen oder beissen, damit der Computer wieder läuft. In der Regel durch einen SW-"Reset". Und wenn die Software dazu nicht mehr in der Lage ist, muß ein Hardware Reset erfolgen.
CCU.IO ist ein dynamisches Programmsystem, das laufend weiterentwickelt wurde. Bei der Weiterentwicklung wurde es immer stabiler, alte Bugs verschwanden, neue kamen rein. Nachdem durch kaltes Duschwasser der Beweis erbracht wurde, daß sich CCU.IO aufhängen kann, wird wohl ein Watchdog implementiert. Der soll CCU.IO mit der Scriptengine wieder auf die Spur bellen/beissen, wenn da mal was schief geht.
Dieser Watchdog war bei HS1 unter Windows XP auf einem robusten Compaq Rechner nicht nötig. Einschalten, und nur nach Stromausfällen wurde neu gestartet. Sogenannter 365/24 Betrieb, oder so.
Im Homematik Forum werden Zahlen gehandelt, wie lange denn CCU oder CCU.IO schon laufen, meist gemessen in Tagen. Dort gibt es auch eine Anleitung, wie man einen Watchdog baut, der ganz brutal die Netzspannung mal kurz trennt, wenn sich "irgendetwas" aufgehangen hat.
Die Brutal-Methode, mal den Netzstecker ziehen, ist auch für Raspi möglich, aber gar nicht schön. Besser also per SW : "sudo reboot".
Der auf dem Raspi eingesetzte Prozessor (Broadcom BCM2835 SoC) hat auch einen eingebauten Watchdog. Vielleicht bekommt man den ja auch ans Laufen ? Mal eben "sudo modprobe bcm2708_wdog", bzw. bcm2708_wdog in /etc/modules schreiben und "sudo apt-get install watchdog" reicht wohl nicht, um die Watchdog Unterstützung scharf zu machen. Siehe auch die Verweise unten.
Das soll der Watchdog bewachen :
pi@xhs01 ~ $ sudo apt-get install watchdog
Reading package lists... Done
Building dependency tree
Reading state information... Done
watchdog is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]?
Setting up watchdog (5.12-1) ...
/run/udev or .udevdb or .udev presence implies active udev. Aborting MAKEDEV invocation.
insserv: warning: script 'mathkernel' missing LSB tags and overrides
insserv: There is a loop between service watchdog and mathkernel if stopped
insserv: loop involving service mathkernel at depth 2
insserv: loop involving service watchdog at depth 1
insserv: Stopping mathkernel depends on watchdog and therefore on system facility `$all' which can not be true!
insserv: exiting now without changing boot order!
update-rc.d: error: insserv rejected the script header
dpkg: error processing watchdog (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
watchdog
E: Sub-process /usr/bin/dpkg returned an error code (1)
pi@xhs01 ~ $
Bis es gelingt, einen Software Watchdog für den Raspi zu installieren, wird es halt ein Hardware Watchdog.
HW Watchdog, Variante 1
Auf der Raspi Platine gibt es eine Möglichkeit, einen "Reset" zu erzeugen. Dafür gibt es Platz für einen Jumper, siehe Foto. Jumper kurzschliessen : Reset. Wie beim PC.
Der HW-Watchdog kann also ein einfaches 5 Volt Relais sein, das man sinnvollerweise mit einem HW-Schalter scharf schaltet. Das Watchdog Relais ist zunächst abgefallen. Es wird durch einen von der Scriptengine erzeugten 0,5 Hertz Takt auf OUT2 des PiFace scharf geschaltet. Wenn kein 0,5 Hertz Takt erzeugt wird, ist der Watchdog inaktiv. Das Watchdog-Relais zieht für circa eine halbe Sekunde an, sobald der 0,5 Hertz Takt länger als ca. 3 Minuten ausbleibt, und erzeugt damit einen Reset.
[Schaltbild, tbd]
Nach jedem erfolgten Reset sendet CCU.IO eine Watchdog-Email zu Dokumentationszwecken.
HW Watchdog, Variante 2
Dieser Ansatz sieht auch gut aus :
Soweit der Plan. Sobald etwas implementiert ist, gibt es hier mehr Infos und erste Erfahrungen.
HW Watchdog, Variante 3
Die Versorgungsspannung von 220 Volt wird einfach kurz weggeschaltet. Die Lösung, den Ping-Watchdog der Steckdosenleiste NETIO 230A für die Raspi WLAN Adresse zu verwenden, fängt leider nur gefühlte 50% der Abstürze ab. Manchmal läuft das WLAN auch weiter, obwohl die Script-Engine nicht mehr tickt.
Was stürzt ab bei CCU.IO ab ?
In der Regel stürzt die Script-Engine ab. Manchmal läuft der Rest von CCU.IO noch weiter, manchmal nicht. Teilweise sind auch Linux Kernel-Bestandteile mit abgeschmiert, wie aus den System-Logs abzulesen ist. Die Abstürze der Kernel Bestandteile geschehen aber in der Regel nicht gleichzeitig mit den CCU.IO Problemen. Teilweise passiert es früher, teilweise später. Leicht erkennbare Auswirkung ist der Ausfall des WiFi Dongle, der per USB angebunden ist. Wenn der USB WiFi Dongle seinen Dienst einstellt, funktioniert die Messwerterfassung über den USB 1Wire Anschluß weiterhin.
Irgendetwas innerhalb von CCU.IO scheint auch "innere Resets" auszulösen. Die Laufzeit von CCU.IO wird immer mit wenigen Stunden angegeben, auch wenn das System schon mehrere Tage läuft.
Diese Prozesse laufen :
UID PID PPID C SZ RSS PSR STIME TTY TIME CMD
pi 2172 1 0 22620 44668 0 Jan08 ? 00:06:41 ccu.io
pi 2438 2172 1 19959 36248 0 Jan08 ? 00:14:07 /usr/local/bin/node /opt/ccu.io/adapter/owfs/owfs.js
pi 2443 2172 6 20396 40464 0 Jan08 ? 01:08:43 /usr/local/bin/node /opt/ccu.io/adapter/rpi/rpi.js
pi 2448 2172 0 19260 26264 0 Jan08 ? 00:02:47 /usr/local/bin/node /opt/ccu.io/script-engine.js
root 2225 1 0 5063 1300 0 Jan08 ? 00:00:00 /opt/owfs/bin/owhttpd -s 4304 -p 2121
root 2226 1 0 11462 1408 0 Jan08 ? 00:05:07 /opt/owfs/bin/owserver -p 4304 -d /dev/ttyUSB0
SW Watchdog allgemein
Einfachste und beste (?) Lösung : sobald CCU.IO hängt, wird per "sudo reboot" ein Neustart erzwungen. Python Programm, Generisches "C", oder so. Das Ganze soll in einem simplen Parallelprozeß laufen, ohne zusätzliches Kernel Modul und so was.
SW Watchdog, geplante nächste Versuche
Alternativ zum kompletten Neustart kann man einfach den Dienst "Scriptengine" neu starten, oder "CCU.IO", statt die ganze Kiste durchzubooten. Dann muß man aber genau wissen, was schiefgegangen ist. Und wenn man nur ca. ein mal pro Tag einen kompletten Reset erlebt, ist das als Übergangslösung eventuell tolerabel.
Jeder angeschlagene Watchdog sollte eine Email auslösen. Für statistische Zwecke. Wenn der Watchdog zu häufig mit kritischen Ein- oder Ausschaltvorgängen kollidiert, ist Feinarbeit angesagt. Das geht am einfachsten, wenn man nach jedem reboot eine Email bekommt.
Man könnte auch einfach (als root) mittels 'crontab -e' folgende Zeile einfügen:
*/10 * * * * /bin/ps -p $(cat /opt/ccu.io/ccu.io.pid) &>/dev/null || /etc/init.d/ccu.io.sh start &>/dev/null
Mal schauen, was es wird.
Gute Software braucht keinen Watchdog!
Die jetzige HSX Software läuft Monate lang stabil. Damit hat das Projekt Watchdog deutlich an Priorität verloren.
Nette Referenzen :
- Arduino Long Time Hardware Watchdog, http://www.playwitharduino.com/?p=291
- Maxim MAX6323/MAX6324, µP Supervisory Circuits with Windowed (Min/Max) Watchdog
- A Hardware watchdog and shutdown button, http://www.linuxfocus.org/English/July2002/article239.shtml
- watchdog - a software watchdog daemon, http://linux.die.net/man/8/watchdog
- Auto-reboot a hung Raspberry Pi using the on-board watchdog timer, http://www.bayerschmidt.com/raspberry-pi/89-auto-reboot-a-hung-raspberry-pi-using-the-on-board-watchdog-timer.html
- ubuntu manuals, watchdog - a software watchdog daemon, http://manpages.ubuntu.com/manpages/lucid/man8/watchdog.8.html
Raspi Systemwatchdog
http://www.gieseke-buch.de/raspberrypi/eingebauten-hardware-watchdog-zur-ueberwachung-nutzen
Page updated
Google Sites
Report abuse