Fehler in FHEM/Raspi - System überwaschen oder zyklischer Neustart//Empfehlung?

[Jogi]

Hallo zusammen,
ich habe vor zwei Tagen durch Zufall bemerkt, dass mit meinem System etwas nicht stimmt.
Ich bin mir dabei nicht sicher, ob es an FHEM oder dem Raspi, oder woran auch immer lag.
Als ich an meinem Rechner saß ist mir aufgefallen, dass eine Steckdose, die per LAN-Ping über das Presence-Modul gesteuert, ist im 30-Sekunden-Takt schaltet. Normalerweise soll diese Steckdose einschalten, sobald per Presence (mit Lan-Ping) erkannt wird, dass der Rechner läuft. Das funktioniert normalerweise auch sehr gut.
Ich konnte den Fehler zuerst nicht finden, bis das ich durch Zufall gesehen habe, dass ich in meinem Sysmon-Plot komische Dinge angezeigt bekomme (siehe Anhang). Normalerweise sieht das anders aus (siehe Anhang).
Ich konnte mir das nicht erklären und habe das System neu gestartet. Seitdem läuft wieder alles normal.
Den Fehler jetzt noch zu finden ist wahrscheinlich wie Glaskugel lesen.
Das ist auch nicht meine Frage.
Ich erlebe es immer mal wieder im Abstand von Monaten, dass das System sich irgendwie verschluckt und durch einen Neustart wieder korrekt funktioniert.
Mal schalten plötzlich die FS20-Steckdosen nicht mehr, mal liest der Jeelink keine Temperaturen mehr ein, und jetzt z.B. so etwas.
Bitte nicht falsch verstehen, ich sage erstens nicht, dass das ein 100%iges FHEM Problem ist und zweitens könnte ich damit auch leben, weil das -gefühlt- 3 bis 5 mal im Jahr passiert. Ausserdem ist mein System so eingerichtet, dass ich per VPN auch von unterwegs alles wieder korrigieren kann.
Manchmal merkt man aber gar nicht, dass das System nicht korrekt läuft.
Daher meine Frage an euch:
Wie überwacht ihr euer System (ich überwache eigentlich nur, ob FHEM läuft)?
Oder rebootet ihr es zyklisch in bestimmten Abständen? Wenn "ja", wie?

Grüße,
Jogi

[frank]

was sagt fhem.log?
hast du auch die ram nutzung in sysmon gelogt?
schau mal hier https://forum.fhem.de/index.php/topic,84372.0.html

[Jogi]

Im Fhem.log und auch im Event-monitor könnte ich nichts besonderes feststellen.
ABER, wie schon geschrieben, ich bin nicht auf der Fehlersuche, sondern meine Fragen sind:

Wie überwacht ihr euer System (ich überwache eigentlich nur, ob FHEM läuft)?
Oder rebootet ihr es zyklisch in bestimmten Abständen? Wenn "ja", wie?

[DS_Starter]

Ich benutze eine Heartbeat-Datei, die von FHEM jede Minute beschrieben wird. Sollte der Schreibzyklus ausbleiben, es wird von einem Linux ! - Watchdog überwacht, wird das System rebootet.
Den Heartbeat kann man loggen und als SVG darstellen - siehe Anhang.

Grüße
Heiko

[ThomasMagnum]

Hallo Heiko,

wärst du so nett und würdest deine Lösung hier zur Verfügung stellen?
Ich habe hier schon einiges gelesen, war aber mit keiner Lösung so wirklich zufrieden.

Gruß, Thomas

[KölnSolar]

Hi Thomas,
ich vermute, dass Heiko den Rpi-watchdog meint, den ich auch nutze. Ich sichere mir dafür mit einem zyklischen at die fhem.save:
define at_FHEM.save at +*00:30:00 {WriteStatefile}
Wie das generell beim Raspi funktioniert ist z.B. hier ganz gut beschrieben.
Grüße Markus

[DS_Starter]

Guten Morgen,

ja ich werde heute Abend die von mir eingesetzte Lösung etwas näher beschreiben.

Grüße,
Heiko

[frank]

Im Fhem.log und auch im Event-monitor könnte ich nichts besonderes feststellen.
ABER, wie schon geschrieben, ich bin nicht auf der Fehlersuche, sondern meine Fragen sind:

Wie überwacht ihr euer System (ich überwache eigentlich nur, ob FHEM läuft)?
Oder rebootet ihr es zyklisch in bestimmten Abständen? Wenn "ja", wie?

hmmmm....

in meinem link geht es um speicherlecks in fhem/perl, die scheinbar einige user haben. deine beschreibung könnte ebenfalls zutreffen.

am ende des threads gibt es dann ein hinweis auf ein notify, das bei auftreten eines speicherproblems fhem neu startet.

also "used ram" plotten/beobachten und mit automatischem fhem neustart ggf speicherproblem beheben.

[DS_Starter]

Wie versprochen hier meine umfassende Beschreibung der bei mir etablierten Lösung.
Die eingesetzte Lösung ist abgeleitet von diesem Beitrag von betateilchen: https://forum.fhem.de/index.php/topic,20553.msg140813.html#msg140813

Die Umsetzung wäre wie folgt:

Die benötigten Kernelmodule installieren

Code Auswählen Erweitern

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

Den watchdog daemon installieren

Code Auswählen Erweitern

apt-get install watchdog

Danach ist der watchdog installiert, aber noch nicht gestartet.

Den automatischen Start des watchdog beim Booten deaktivieren

Code Auswählen Erweitern

update-rc.d watchdog remove

Ganz wichtig, damit man sich nicht durch einen evtl. Konfigurationsfehler quasi den Boden unter den Füßen wegzieht und das System ständig rebootet.

Die Konfigurationsdatei für den watchdog bearbeiten

In der Datei /etc/watchdog.conf werden folgende beiden Zeilen aktiviert:

Code Auswählen Erweitern

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

Der Rest der Datei bleibt vorerst unangetastet.

Dateiüberwachung einrichten

Ich benutze die Dateiüberwachung mit einer ,,heartbeat"-Datei, die regelmäßig von FHEM angefasst wird, um festzustellen, wenn FHEM nicht mehr korrekt funktioniert. In diesem Fall würde keine Datei mehr aktualisiert.

In die Datei /etc/watchdog.conf habe ich folgende Zeilen eingefügt:

Code Auswählen Erweitern

file = /opt/fhem.heartbeat
change = 700

Dadurch wird das System neu gestartet, wenn der Zeitstempel der genannten Datei mehr als 700 Sekunden nicht aktualisiert wurde.

Bevor wir nun den watchdog starten können, müssen wir die zu überwachende Datei einmalig initialisieren und dem user fhem zuordnen

Code Auswählen Erweitern

touch /opt/fhem.heartbeat
chown fhem:dialout /opt/fhem.heartbeat

Den watchdog starten

In meiner Lösung habe ich ein Device "watchdog" mit dem Modul "98_serviced" definiert, welches beim Start von FHEM zeitlich verzögert den Linux Watchdog-Dienst startet. Der verzögerte Start stellt sicher, dass mit Sicherheit erst die Heartbeat-Datei geschrieben wurde bevor der Dienst startet.

Raw-Definition des Watchdog-Devices:

Code Auswählen Erweitern

defmod watchdog serviced watchdog
attr watchdog userattr genericDeviceType homebridgeMapping:textField-long
attr watchdog alias Service watchdog
attr watchdog cmdIcon restart:rc_REPEAT stop:rc_STOP status:rc_INFO start:rc_PLAY
attr watchdog comment startet und stoppt den Linux watchdog (http://sds1.myds.me/MediaWiki/index.php?title=Watchdog)\
automatisch bei start/stop von FHEM.\
Start mit 90s Verzögerung da erst AT "heartbeat" laufen muss um die Controldatei zu touchen.
attr watchdog devStateIcon Initialized|status:light_question error|failed:ios-NACK running:ios-on-green:stop stopped:ios-off:start stopping:ios-set_off-green .*starting:ios-set_on
attr watchdog icon hue_room_garage
attr watchdog room Dienste->Allgemein
attr watchdog serviceAutostart 90
attr watchdog serviceAutostop 10
attr watchdog serviceGetStatusOnInit 1
attr watchdog verbose 3
attr watchdog webCmd start:stop:status

Dazu korrespondierend gibt es in fhem eine at-Definition, in der die Heartbeat-Datei /opt/fhem.heartbeat minütlich berührt wird:

Code Auswählen Erweitern

defmod heartbeat at +*00:01:00 {qx(touch /opt/fhem.heartbeat)}
attr heartbeat DbLogExclude state
attr heartbeat comment Touch einer Datei für die Verwendung durch Watchdog an. \
Das Reading "touch" wird bei jedem Zyklus alternierend auf 0 bzw. 1 gesetzt zum Logging und Darstellung in SVG.\
\
(http://sds1.myds.me/MediaWiki/index.php?title=Watchdog#Den_RaspberryPi_per_watchdog_mit_.2Fdev.2Fwatchdog_.C3.BCberwachen)
attr heartbeat disable 0
attr heartbeat icon clock
attr heartbeat room Dienste->Monitoring
attr heartbeat userReadings touch { if(ReadingsVal($name,"touch",0) == 0) {1} else {0} }


Das UserReading "touch" wird mit jedem Touchzyklus alternierend mit 0 oder 1 geschrieben und in meiner DB geloggt. Eine SVG-Definition zeigt die grafische Auswertung wie oben gezeigt für das Monitoring an.

Die Gesamtlösung läuft bei schon lange sehr zuverlässig. Sie hat auch den Vorteil, dass man sich bei einem normalen Stopp von FHEM um nichts kümmern muss, weil der watchdog-Dienst im Linux über das gesetzte Attribut "serviceAutostop" im watchdog-Device (98_serviced) automatisch mitgestoppt werd. Würde FHEM abstürzen wäre das nicht der Fall und das System würde nach 700 Sekunden rebootet. Beim Start ist es ähnlich. Erst wenn FHEM aktiv ist, wird der watchdog-Dienst im Linux gestartet.

Grüße,
Heiko

[Jogi]

Vielen Dank für die Infos, da ist auch eine Lösung für mich bei.
Gruß,
Jogi

[Invers]

In meiner Lösung habe ich ein Device "watchdog" mit dem Modul "98_serviced" definiert, welches beim Start von FHEM zeitlich verzögert den Linux Watchdog-Dienst startet. Der verzögerte Start stellt sicher, dass mit Sicherheit erst die Heartbeat-Datei geschrieben wurde bevor der Dienst startet.

Kannst du den Inhalt des Moduls 98_serviced noch hier einfügen?

Danke.

EDIT:
Sorry, war ein Missverständnis. Ich habe gerade mitbekommen, dass dieses Modul schon existiert. Kannte ich noch nicht. Da war ich wohl nicht so gut drauf, als ich das gelesen habe.

[ThomasMagnum]

Wie versprochen hier meine umfassende Beschreibung der bei mir etablierten Lösung.
Die eingesetzte Lösung ist abgeleitet von diesem Beitrag von betateilchen: https://forum.fhem.de/index.php/topic,20553.msg140813.html#msg140813

Die Umsetzung wäre wie folgt:

Die benötigten Kernelmodule installieren

Code Auswählen Erweitern

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

Mit aktuellem Kernel muss der folgende Befehl ausgeführt werden um das Watchdog Modul zu aktivieren:

Code Auswählen Erweitern

sudo modprobe bcm2835_wdt

Gruß, Thomas

[Gisbert]

Hallo Heiko,

kannst du eventuell der folgende Auffälligkeit (Fehler möchte ich es noch nicht nennen, da die Ursache auch bei mir liegen könnte) nachgehen?

Wenn man die Konfigurationsdateien mit "rereadcfg" in der Fhem-Kommandozeile einliest, dann stoppt das Modul serviced den Linux-watchdog, startet ihn aber nicht nach Ablauf der Zeit "serviceAutostart" neu. Da der Befehl "rereadcfg" vermutlich häufig im Umlauf ist, hat man danach den watchdog nicht mehr laufen.

Was macht "rereadcfg" genau? Offensichtlich was anderes, als Fhem zu stoppen und neu zu starten.

Viele Grüße Gisbert

Edit:
Mit "Shutdown Restart" in der Fhem-Kommandozeile erhält man das erwartete Verhalten, d.h. der watchdog wird beendet und nach dem Neustart von Fhem nach Ablauf der Zeit "serviceAutostart" wieder gestartet.

Edit2: Ich hab das Verhalten auch in den Beitrag "Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern" verlinkt.

[DS_Starter]

Hallo Gisbert,

schaue ich mir nach den Feiertagen an.  Am besten antworte ich dann in dem anderen Thread.
Mir war aber noch nie etwas aufgefallen was du beschreibst.

viele Grüße und ein schönes Fest
Heiko

[Gisbert]

Hallo DS_Starter,

ich stelle wiederholt fest, dass der watchdog noch einem reboot des RPi nicht startet.
Ich habe noch keine Idee woran es liegen könnte.

Im log erscheinen folgende Einträge, die mit dem watchdog zu tun haben:

Code Auswählen Erweitern

2019.02.23 12:47:28 0: Server shutdown
2019.02.23 12:47:28 1: Shutdown executed
2019.02.23 12:47:28 3: watchdog: stopping service "watchdog" due to shutdown
2019.02.23 12:47:29 3: watchdog: shutdown sequence of service watchdog finished
2019.02.23 12:48:19 3: watchdog: get status of service "watchdog" due to startup
2019.02.23 12:48:19 3: watchdog: starting service "watchdog" with delay of 300 seconds
2019.02.23 12:53:24 3: watchdog: Error: Job for watchdog.service canceled.


Die Definition meines watchdogs (hab in manuell gestartet):

Code Auswählen Erweitern

defmod watchdog serviced watchdog
attr watchdog userattr genericDeviceType homebridgeMapping:textField-long
attr watchdog alias Service watchdog
attr watchdog cmdIcon restart:rc_REPEAT stop:rc_STOP status:rc_INFO start:rc_PLAY
attr watchdog comment startet und stoppt den Linux watchdog (http://sds1.myds.me/MediaWiki/index.php?title=Watchdog)\
automatisch bei start/stop von FHEM. Start mit 300s Verzögerung, da erst AT "heartbeat" laufen muss, um die Controldatei zu touchen.
attr watchdog devStateIcon Initialized|status:light_question error|failed:ios-NACK running:ios-on-green:stop stopped:ios-off:start stopping:ios-set_off-green .*starting:ios-set_on
attr watchdog group Performance
attr watchdog icon hue_room_garage
attr watchdog serviceAutostart 300
attr watchdog serviceAutostop 5
attr watchdog serviceGetStatusOnInit 1
attr watchdog verbose 3
attr watchdog webCmd start:stop:status

setstate watchdog running
setstate watchdog 2019-02-23 19:42:51 error none
setstate watchdog 2019-02-23 19:42:51 state running
setstate watchdog 2019-02-23 19:42:51 status Active: active (running) since Sat 2019-02-23 19:42:51 CET;; 131ms ago


Wo muss ich anfangen zu suchen?

Viele Grüße Gisbert