OWX kann FHEM abschiessen ?!?

hexenmeister · 22 Mai 2014, 23:59:10

Ich denke nicht, denn der erste grep findet sich selbst, denn auch in seiner Befehlszeile ein 'fhem' vorkommt.
Für das Ergebnis ist es egal, ob ich die Liste aller Prozesse zuerst von allen 'greps' befreie und dann nur die 'fhem' drin lasse, oder umgekehrt. Im Sinne der Performance ist meine Variante jedoch günstiger, denn es wird im ersten Schritt mehr aus der Liste entfernt, so dass der zweite Durchlauf auf eine kürzere Liste angewendet wird.

Es ist wohl doch kein Zufall, es ist nachvollziehbar und wiederholbar.

P.A.Trick · 23 Mai 2014, 00:28:29

Du hast gewonnen obwohl die Performance wohl vernachlaessigbar sein sollte

hexenmeister · 23 Mai 2014, 01:03:02

Da hast Du recht, bei der Menge von laufenden Prozessen wird man das kaum messen können

Spezialtrick · 27 Mai 2014, 17:32:56

So ich habe an meiner Konfiguration nichts verändert und habe herausgefunden, dass nicht nötig ist das Attribut "attr global mseclog 1" in der fhem.cfg zu setzen, damit der Watchdog korrekt arbeitet. Es reicht schon aus, wenn ich die fhem.cfg einmal abspeicher. Unmittelbar danach wirf FHEM immer vom Watchdog gefunden.

hexenmeister · 28 Mai 2014, 00:08:09

ZitatEs reicht schon aus, wenn ich die fhem.cfg einmal abspeicher.

verstehen tue ich das nicht...

Spezialtrick · 28 Mai 2014, 12:01:56

Verstehst du meine Ausführungen nicht oder warum sich der Watchdog gerade so verhält? Für mich ist das Verhalten des Watchdogs nicht so tragisch, da es mir ja nun bekannt ist und ziemlich einfach zu beheben ist.

hexenmeister · 28 Mai 2014, 13:40:28

ZitatVerstehst du meine Ausführungen nicht oder warum sich der Watchdog gerade so verhält?

Dich verstehe ich schon

Ich verstehe nicht, wie zu diesem Verhalten kommen kann

und was das Speichern von fhem.cfg mit dem Finden von Prozessen zu tun hat...

Michi240281 · 21 Januar 2015, 10:32:44

Zitat von: hexenmeister am 07 Dezember 2013, 20:53:03
Hallo,

ich kann gern versuchen zu helfen, den Watchdog zum Laufen zu bekommen. Ist zwar eher für Raspberry Pi optimiert, sollte aber mit minimalsten Anpassungen auch auf anderen Unix-basierten Systemen funktionieren.

Das Ganze besteht aus zwei Teilen. Einmal eine Log-Datei in FHEM, die per AT-Befehl minütlich beschrieben wird. Demgegenüber steht ein Bash-Script, das in einer Schleife prüft, wann die letzte 'Lebensmeldung' von FHEM vorlag. Unterbleibt diese länger als 5 Minuten, wird die ggf. vorhandene FHEM-Instanz gekillt und eine neie gestartet. Dann gibt es not etwas Visualisierung mit FHEM, ist aber nicht wesentlich.

Zum Installieren müssen zunächt einige Dateien aus dem GitHub geholt werden. Sie gehören ins FHEM-Hauptverzeichnis.

killfhem.sh
Dieses Script beendet FHEM. Wird in anderen Scripten genutzt.
Ich sehe gerade einen kleinen Fehler drin, auch wenn dieser normalerweise nicht zum Vorschein kommen dürfte, werde ich ihn gleich fixen...
killwatchdog.sh
Beendet Watchdog. Wird in Scripten benutzt.
runfhem.sh
Startscript für FHEM. Prüft, ob der Server ggf. bereits ausgeführt wird.
runwatchdog.sh
Startet Watchdog. Sorgt dafür, dass nur eine Instanz aktiv ist.
watchdogloop.sh
Der eigentliche Watchdog.
startfhem
Dieses Script startet Watchdog und FHEM-Server. Darf auch 'per Hand' aufgerufen werden.
stopfhem
Dieses Script beendet Watchdog und FHEM-Server. Allei FHEM zu beenden führt ja nicht zum Erfolg Darf auch 'per Hand' aufgerufen werden.
Bis auf die letzten zwei sollten die Scripte nicht manuell gerufen werden.
Auchtung! Fast alle diese Scripte haben ein fest 'verdrahtetes' Home-Verzeichnis:
Code Auswählen Erweitern
home=/opt/fhem
Bitte ggf. anpassen. Ich werde das vielleicht bei Gelegenheit umbauen und etwas flexibler gestallten.

Die Datei etc_init.d_fhem_script.txt ist kein ausführbares Script! Es hält den Inhalt des FHEM-Verwaltungs-Scriptes /etc/init.d/fhem, damit ich alles an einer Stelle (in GutHub) habe. Es ist nur ein Beispiel, das zeigt, wie man den Startscript umbauen soll, damit beim Start von Betriebssystem auch Watchdog hochgefahren wird. Beim Start/Stop-Vorgang sollen die startfhem / stopfhem Scripte genutzt werden. Das ist alles.

Bei den Scripten ist sicherzustellen, dass diese ausführbar sind: chmod a+x <Dateiname>
Und sie sollten einem passenden Benutzer gehören (z.B. fhem): chown fhen:fhen <Dateiname>
Der Benutzer, unter dessen Account FHEM ausgeführt wird, muss in die sudo-Gruppe. Damit stellen die Scripte sicher, dass sie die Prozesse in jedem Fall benden können: sudo usermod -aG sudo fhem
Und noch muss dieser User diese Scripte ohne Abfrage mit hohen Rechten ausführen dürfen. Dafür muss die Datei /etc/sudoers ergänzt werden:
Code Auswählen Erweitern
fhem ALL=(ALL) NOPASSWD: /opt/fhem/runwatchdog.sh, /opt/fhem/killwatchdog.sh, /opt/fhem/watchdogloop.sh, /opt/fhem/runfhem.sh, /opt/fhem/killfhem.sh
Bitte vorsichtig mit dieser Datei! Das sind sicherheitsrelevante Einstellungen! Ist sie kaputt und auch noch der Root-User deaktiviert, hat man sich ausgesperrt.

Bevor man Watchdog aktiviert, sollte man sicherstellen, dass FHEM-Teil richtig läuft, ansonsten wird der FHEM alle 5 Minuten immer und immer wieder restartet.

in fhem.cfg wird folgendes ergäntz:
Code Auswählen Erweitern
# Definition eines Dummy-Objektes fuer 'Alive'-Meldungen define NN_TE_DMST01.Server_Heartbeat dummy # Protokoliert Zeitpunkt der letzten Änderung (in Objekt-Eigenshaften) attr NN_TE_DMST01.Server_Heartbeat userReadings lastChange { CurrentTime() } # Definition der Log-Datei define FileLog_NN_TE_DMST01.Server_Heartbeat FileLog ./log/NN_TE_DMST01.Server_Heartbeat-%Y-%m.log NN_TE_DMST01.Server_Heartbeat attr FileLog_NN_TE_DMST01.Server_Heartbeat logtype myServerHeartbeat:Plot,text # Visualisierung mittels eines Diagramms define 0.wlHeartbeat SVG FileLog_NN_TE_DMST01.Server_Heartbeat:myServerHeartbeat:CURRENT # Routine zur regelmaessigen Änderungen des Wertes des Dummy-Objektes define tickHeartbeat at +*00:01:00 {tickHeartbeat('NN_TE_DMST01.Server_Heartbeat');;} attr tickHeartbeat alignTime 00:00 # Log-Datei des Watchdogscriptes verfügbar machen define FileLog_wathdog FileLog ./log/watchdog.log fakelog # Visualisierung für Watchdog-Log define 0.wlWatchdog SVG FileLog_wathdog:myWatchdog:CURRENT

Hier wird eine Methode 'tickHeartbeat' genutzt, die irgendwo abgelegt werden muss. Bei mir liegt diese in der Datei <FHEM-Root>/FHEM/99_MyUtils.pm
Dort ist folgendes hinzufügen:
Code Auswählen Erweitern
# Liefert aktueller Zeitstempel sub CurrentTime() { return strftime("%H:%M:%S", localtime()); } # --- server heartbeat / watchdog --- sub tickHeartbeat($) { my ($device) = @_; my $v = _getDeviceValueNumeric($device); $v = $v+1; if($v>=60) {$v=0;} fhem("set $device $v"); } # Liefert den aktuelen numerisschen Wert eines Ger?tezustandes. # Setzt bei Bedarf die symbolische Werte (up, down) in ihre # Zahlenwertrepresentationen um. sub _getDeviceValueNumeric($) { return _convertSymParams(Value($_[0])); } # Setzt Parameter-Werte fuer symbolische Werte in ihre Zahlenwerte um. # up = 100, down = 0 sub _convertSymParams($) { my $value = $_[0]; # Endwerte und andere symbolischen Konstanten beruecksichtigen, # Gross-/Kleinschreibung ignorieren $value = lc($value); if($value eq "down" || $value eq "runter" || $value eq "off") { return 0; } elsif($value eq "up" || $value eq "hoch" || $value eq "on") { return 100; } elsif($value =~ /schatten.*/) { return 80; } elsif($value =~ /halb.*/ ) { return 60; } # Numerische Werte erwartet my $ivalue = int($value); if($ivalue < 0) { return 0; } elsif($ivalue > 100) { return 100; } elsif($ivalue > 0) { return $ivalue; } # Pruefung, ob bei 0 da wirklich eine Nummer war if($value eq $ivalue or $value eq "0 %" or $value eq "0%") { return 0; } # Default-Fall: Bei unbekannten Werten soll Rollo offen sein return 100; }

Man könnte das auch einfacher realisieren, fand ich aber schöner fürs Plot.

Dann haben wir nur noch

myServerHeartbeat.gplot
und
myWatchdog.gplot
Das sind die Plots und gehören natürlich nach <FHEM-Root>/www/gplot

So, da habe ich bestimmt noch etwas vergessen.
Bitte ausprobieren und ggf. melden, wenns nicht laufen will.

Grüße,

Alexander

Links:
http://s6z.de/cms/index.php/homeautomation/fhem/23-fhem-watchdog
https://github.com/hexenmeister/MyFHEM

Hallo Alexander,

ich würde gerne diesen Fhem Watchdog bei mir implementieren. Fhem läuft auf dem RPi.

Nun habe ich jedoch 2 Fragen dazu:

1. Bei den Dateien, die ins Fhem Hauptverzeichnis sollen, schreibst du was von runfhem.sh und killfhem.sh. Diese sind aber nicht im GitHub runterzuladen?!?

2. In meinem Hauptverzeichnis liegen bereits die Skripte "startfhem" und "stopfhem". Muss ich diese durch die von GitHub ersetzen?

Besten Dank und viele Grüße
Michael

hexenmeister · 21 Januar 2015, 15:22:13

Moin!

1. Doch, alle da

https://github.com/hexenmeister/MyFHEM/blob/master/killfhem.sh
https://github.com/hexenmeister/MyFHEM/blob/master/runfhem.sh

2. Ja, schau aber hinein, wenn da spezielle Anpassungen existieren, musst Du diese ggf. übernehmen.

Grüße,

Alexander

Aladin222 · 19 März 2015, 11:19:22

Hi ,

so da habe ich mich nun auch mal dran gewagt

Code Auswählen

# Log-Datei des Watchdogscriptes verfügbar machen
define FileLog_wathdog FileLog ./log/watchdog.log fakelog
attr FileLog_wathdog group Watchdog
attr FileLog_wathdog room 9.03_Tech

ist das FileLog_wathdog ein Tippfehler ?

Wenn ich den Watchdog ( watchdogloop.sh ) anschmeiße ,so läuft er & Fhem unter dem User fhem - soweit ja richtig , oder ?

Wenn ich mit ./killwatchdog.sh den Watchdog stoppen möchte kommt :

Code Auswählen

Stop watchdog
./killwatchdog.sh: 4: ./killwatchdog.sh: killall: not found

[Edit] ok, ein apt-get install killall brachte leider auch keinen Erfolg aber
mit aptitude install psmisc kennt mein Linux nun auch den Befehl killall und das beenden funktioniert nun !!!

Stoppe ich Fhem aus dem Terminal - so sehe ich das der Watchdog erkennt das fhem dead ist ,aber es hakt am Neustart

, im watchdog_err.log kommt :

Code Auswählen

sudo: effective uid is not 0, is sudo installed setuid root?
sudo: effective uid is not 0, is sudo installed setuid root?

So , als N00b habe ich also 2 Probleme :
Mein Linux kann mit Killall nix anfangen und irgendwas stimmt mit den rechten nicht , oder ?
[Edit]
hmmm, ok Killall läuft nun - somit funktioniert jetzt auch der Neustart automatisch ....Warum ? Kein Plan , hatte gestern ewig verbracht das ans laufen zu bekommen und nun lüppt es .

Irgendwas scheint nun noch strubbelig zu sein ... der Sägezahnplot ist da und sieht gut aus !
Der Watchdogplot ist komplett leer - auch das watchdog.log ist komplett ohne Eintrag .
Das watchdog_err.log ist nun auch komplett ohne Eintrag !

Prof. Dr. Peter Henning · 19 März 2015, 12:41:45

Ich halte ehrlich gesagt mehr davon, den eingebauten Hardware-WD zu nutzen (auch beim Cubie).

LG

pah

Aladin222 · 19 März 2015, 13:03:49

erstmal Danke für die Antwort

hmmmm, ich weiß leider nicht wie ich dies mit dem eingebauten Watchdog realisiert bekomme ?
Versuche ja noch immer den o.g. Lösungsansatz zu verstehen *schäm
Zur Zeit steuere ich eine Chlordosierpumpe mit Fhem und es wäre wirklich blöd wenn die Dosierung ausfällt !
Mit der angebotenen Lösung würde der Server neu gestartet und es gibt die Möglichkeit auf Ursachenforschung zu gehen darum gefällt mir diese Lösung sehr.
Dazu werde ich mir gerne den internen WD genauer ansehen und versuchen diesen zu begreifen

Glaube nun die Funktionsweise etwas besser zu verstehen ( Betonung liegt auf etwas )

Den Hinweiß : define FileLog_wathdog FileLog ./log/watchdog-%Y-%m.log fakelog hab ich überlesen - bin da mehr nach dem Blog gegangen ...
Damit zeigt auch der Watchdogplot etwas an

Nochmal fix zum Verständnis - Das Logfile watchdog.log ist ein temporäres Logfile ,welches nicht weiter benötigt wird , oder ?
Was passiert bei einem update von Fhem ? Muss dabei noch etwas beachtet werden ?

hexenmeister · 19 März 2015, 13:37:05

Zitat von: Prof. Dr. Peter Henning am 19 März 2015, 12:41:45
Ich halte ehrlich gesagt mehr davon, den eingebauten Hardware-WD zu nutzen (auch beim Cubie).

Je nach Verwendungszweck. Mit dem Hardware-WD kann man (finde ich) ganz gut die Probleme mit dem Betriebsystem oder gar Hardware abfangen. Mein Script überwacht nur die FHEM-Instanz. Ich habe gerne beides getrennt.

hexenmeister · 19 März 2015, 13:49:22

watchdog.log ist nicht temporär, da sind die Ausgaben des WD-Scriptes drin.
In dem watchdog_err sind die Meldungen, die auf std_err ausgegeben werden (auch von FHEM).

Aladin222 · 19 März 2015, 14:11:18

Zitat von: hexenmeister am 19 März 2015, 13:49:22
watchdog.log ist nicht temporär, da sind die Ausgaben des WD-Scriptes drin.

die Ausgaben vom WD-Scriptes landen bei mir im watchdog-2015-03.log .... oder wo hab ich nun wieder einen Knoten im Kopf ?

Das watchdog.log ist bei mir leer !?