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
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 (https://forum.fhem.de/index.php/topic,84372.0.html)
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?
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
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
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 (http://www.gieseke-buch.de/raspberrypi/eingebauten-hardware-watchdog-zur-ueberwachung-nutzen) ganz gut beschrieben.
Grüße Markus
Guten Morgen,
ja ich werde heute Abend die von mir eingesetzte Lösung etwas näher beschreiben.
Grüße,
Heiko
Zitat von: Jogi am 10 November 2018, 17:24:28
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.
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
modprobe bcm2708_wdog
echo "bcm2708_wdog" | tee -a /etc/modules
Den watchdog daemon installieren
apt-get install watchdog
Danach ist der watchdog installiert, aber noch nicht gestartet.
Den automatischen Start des watchdog beim Booten deaktivieren
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:
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:
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
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:
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:
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
Vielen Dank für die Infos, da ist auch eine Lösung für mich bei.
Gruß,
Jogi
ZitatIn 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.
Zitat von: DS_Starter am 12 November 2018, 19:56:44
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
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:
sudo modprobe bcm2835_wdtGruß, Thomas
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.
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
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:
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):
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
Hallo Gisbert,
das habe ich bei mir auch manchmal nach einem Reboot.
Da ich bis jetzt auch nicht gefunden habe woran es liegt, ahbe ich mir einen Workaround gebaut und restarte den watchdog mit einem Notify beim Start:
defmod N.watchdog.service.restart notify .*watchdog:.*canceled.* set watchdog start
attr N.watchdog.service.restart alias Restart Watchdog-Service
attr N.watchdog.service.restart disable 0
attr N.watchdog.service.restart readLog 1
attr N.watchdog.service.restart room Dienste->Allgemein
attr N.watchdog.service.restart verbose 2
Damit ist die Sache für mich ok. Vllt. finde ich noch etwas, aber momentan bin ich mit anderen Dingen beschäftigt.
Grüße
Heiko
Hallo Heiko,
vielen Dank für deine schnelle Antwort.
Immerhin gut zu wissen, dass es anscheinend nicht so einfach zu beheben ist, schon mal gar nicht für mich.
Ich hab deinen Workaround gleich übernommen.
Viele Grüße Gisbert
Alles mal so übernommen. Bekommen nun aber einen Error im State, wo mir absolut der Durchblick fehlt.
Internals:
CFGFN
DEF watchdog
FUUID 5f1822bf-f33f-e9d9-a123-55c8adb8c65ab977
NAME fhem.watchdog
NOTIFYDEV global
NR 1888
NTFY_ORDER 50-watchdog
SERVICENAME watchdog
STATE error
TYPE serviced
VERSION 1.2.5
READINGS:
2020-07-22 14:01:53 error We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. sudo: no tty present and no askpass program specified
2020-07-22 14:01:53 state error
helper:
Attributes:
alias Service watchdog
cmdIcon restart:rc_REPEAT stop:rc_STOP status:rc_INFO start:rc_PLAY
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.
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
group Software
icon hue_room_garage
room Services
serviceAutostart 90
serviceAutostop 10
serviceGetStatusOnInit 1
userattr genericDeviceType homebridgeMapping:textField-long
webCmd start:restart:stop:status
Schon mal mit der Fehlermeldung google bemüht!?
Nein?
Ich schätze: fhem darf nicht 'sudo' ohne Passwort (zumindest bzgl. service start)
Gruß, Joachim
Ich habe gegoogled bin aber daraus nicht schlau geworden. Wieso will fhem per sudo etwas tun ? Ich all den Beschreibungen zu der watchdog einrichtung stand nichts von sudo bzw. wie man fhem dementsprechend konfiguriert :(
Naja, wenn du systemctl start servicname auf der Console ausführen willst, brauchst du root Rechte -> sudo...
Ebenso fhem, welches mit dem verwendeten Modul genau das tut...
EDIT: was übrigens beim verwendeten Modul serviced beschrieben ist https://forum.fhem.de/index.php/topic,79952.msg719659.html#msg719659
Gruß, Joachim
Genau der Link hat wohl noch in einer der Beschreibungen gefehlt. Anyway...
Ich nutze vermutlich systemctl und lt. Beschreibung soll die /etc/sudoers angepasst werden. da steht bei mir aber schon ein eintrag
# User alias specification
fhem ALL=NOPASSWD: ALL
Ist das nicht gleichbedeutend mit ... ?
fhem ALL=(ALL) NOPASSWD:/bin/systemctl
Wie hast du den Eintrag in die sudoers gemacht!?
Tatsächlich DIREKT in die sudoers!?
Bearbeiten besser (ausschließlich) mittles visudo!
Weil dabei auch checks gemacht werden...
Aktuell ist es eher so: jeder User hat eine eigene Datei unter /etc/sudoers.d/ (der User pi sollte dort schon eine haben)...
Eventuell mal bzgl. sudoers etc. informieren!
Schau dir doch mal die beiden Einträge an!!
Und gleichbedeutend!?
NEIN!!
Das eine soll (aber stimmt wohl nicht ;) ) ALLES OHNE PASSWORT erlauben...
...der Eintrag im Link für das Modul eben nur systemctl...
EDIT: das wäre wohl richtig(er)
fhem ALL=(ALL) NOPASSWD: ALL
EDIT: aber macht auch deutlich weit auf!!!!!
Gruß, Joachim
Also hab nochmal geschaut. Es gibt nur /etc/sudoers und diese enthält....
# User alias specification
fhem ALL=NOPASSWD: ALL
# Cmnd alias specification
# User privilege specification
root ALL=(ALL:ALL) ALL
fhem ALL=(ALL) NOPASSWD: ALL
....
fhem ALL=NOPASSWD: ALL
...
fhem ALL=(ALL) NOPASSWD: ALL
Mache bitte nur EINE Zeile ... sudo arbeitet die Config von oben nach unten ab. Die erste Zeile die trifft .... und die bitte so, wie MadMax schrieb.
Trotzdem die Empfehlung:
1. Arbeite nicht mit der /etc/sudoers sondern baue Dir eine eigene unter /etc/sudoers.d. Die braucht auch nur FHEM-Config zu enthalten. Wird automatisch geladen.
2. Nicht global öffnen! Ist beinahe schlimmer, als fhem unter root arbeiten zu lassen (was schon katastrophal wäre)
Ich habe es jetzt erstmal bei der einen sudoers belassen, bis es funktioniert.
Auch wenn ich nur fhem ALL=(ALL) NOPASSWD: ALL verwende hat das keinerlei Auswirkung. :'(
Womit bearbeitest Du die sudoers?
Über die Konsole mit sudo nano /etc/sudoers
Was sagt das System bei den üblichen Verdächtigen? syslog, kern.log etc ...
bei einem normalen Debian-Pi ist es z.B. so eingerichtet: /etc/sudoers.d/010_pi-nopasswd
pi ALL=(ALL) NOPASSWD: ALL
Zitat von: en-trust am 23 Juli 2020, 14:29:13
Über die Konsole mit sudo nano /etc/sudoers
huh,
bitte nicht einfach von Hand die sudoers Datei bearbeiten ...
Ein Syntax Fehler und Du bist raus
am besten mit
sudo visudo
Zitat von: Wuppi68 am 23 Juli 2020, 16:24:21
huh,
bitte nicht einfach von Hand die sudoers Datei bearbeiten ...
Ein Syntax Fehler und Du bist raus
am besten mit sudo visudo
Vielleicht wird's ja das 2te Mal beachtet ;)
https://forum.fhem.de/index.php/topic,93050.msg1073907.html#msg1073907
EDIT: gut, vielleicht nicht "exponiert" genug... :-\ ;)
Gruß, Joachim
Zitat von: Wernieman am 23 Juli 2020, 14:35:13
Was sagt das System bei den üblichen Verdächtigen? syslog, kern.log etc ...
bei einem normalen Debian-Pi ist es z.B. so eingerichtet: /etc/sudoers.d/010_pi-nopasswd
pi ALL=(ALL) NOPASSWD: ALL
Hab nachgesehen und es gibt diese sudoers.de mit genau dem Eintrag auch bei mir. Soll dort jetzt noch dieser fhem Eintrag rein ?
Liest du was wir schreiben!?
Was sagt dir der Name der Datei!?
Jeder User kann/hat seine EIGENE Datei...
EDIT: Siehe (noch mal): https://forum.fhem.de/index.php/topic,93050.msg1073907.html#msg1073907
Also wie (mehrfach) geschrieben: leg eine Datei für fhem an:
sudo cp /etc/sudoers.d/010_pi-nopasswd /etc/sudoers.d/010_fhem-nopasswd
sudo visudo -f /etc/sudoers.d/010_fhem-nopasswd
Der erste Schritt ist optional, schadet aber nicht, dann hast du schon mal eine passende "Vorlage"...
Gruß, Joachim
Danke aber...
Ich habe nun alles gemacht, wie ihr es mir Scheibchenweise mitgeteilt habe. Den fhem ALL Passus aus der sudoers.d noch komplett rausgeschmissen und dafür eine neue Sudoers.d aufgemacht.
Internals:
DEF watchdog
FUUID 5f1822bf-f33f-e9d9-a123-55c8adb8c65ab977
NAME fhem.watchdog
NOTIFYDEV global
NR 1366
NTFY_ORDER 50-fhem.watchdog
SERVICENAME watchdog
STATE running
TYPE serviced
VERSION 1.2.5
READINGS:
2020-07-24 10:49:27 error none
2020-07-24 10:49:27 state running
2020-07-24 10:49:27 status Active: active (running) since Fri 2020-07-24 10:49:27 CEST; 134ms ago
helper:
Attributes:
alias Service watchdog
cmdIcon restart:rc_REPEAT stop:rc_STOP status:rc_INFO start:rc_PLAY
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.
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
group Software
icon hue_room_garage
room Services
serviceAutostart 90
serviceAutostop 10
serviceGetStatusOnInit 1
userattr genericDeviceType homebridgeMapping:textField-long
webCmd start:restart:stop:status
Scheint jetzt zu laufen. Man lernt nie aus, vorallem bei fhem.
Das war nicht FHEM sondern Unix .....