OWX kann FHEM abschiessen ?!?

[hexenmeister]

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]

Du hast gewonnen obwohl die Performance wohl vernachlaessigbar sein sollte ;-)

[hexenmeister]

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

[Spezialtrick]

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]

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

verstehen tue ich das nicht...

[Spezialtrick]

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]

Verstehst 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]

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]

home=/opt/fhemBitte 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]

fhem ALL=(ALL) NOPASSWD: /opt/fhem/runwatchdog.sh, /opt/fhem/killwatchdog.sh, /opt/fhem/watchdogloop.sh, /opt/fhem/runfhem.sh, /opt/fhem/killfhem.shBitte 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]

# 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]

# 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]

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]

Hi ,

so da habe ich mich nun auch mal dran gewagt :-)

Leider ist der Thread nun wirklich etwas unübersichtlich geworden 

Aaaaalso , bei mir läuft Fhem auf einem Cubietruck .
Von GitHub habe ich mir :

https://github.com/hexenmeister/MyFHEM/blob/master/watchdogloop.sh
https://github.com/hexenmeister/MyFHEM/blob/master/runwatchdog.sh
https://github.com/hexenmeister/MyFHEM/blob/master/killwatchdog.sh
https://github.com/hexenmeister/MyFHEM/blob/master/startfhem
https://github.com/hexenmeister/MyFHEM/blob/master/stopfhem
https://github.com/hexenmeister/MyFHEM/blob/master/FHEM/99_myUtils.pm
https://github.com/hexenmeister/MyFHEM/blob/master/www/gplot/myServerHeartbeat.gplot
https://github.com/hexenmeister/MyFHEM/blob/master/www/gplot/myWatchdog.gplot
https://github.com/hexenmeister/MyFHEM/blob/master/etc_init.d_fhem_script.txt

lt. Anleitung vom Blog ( http://s6z.de/cms/index.php/homeautomation/fhem/23-fhem-watchdog ) geladen und eingebaut !

Hier im Forum bin ich nun noch zusätzlich auf :
https://github.com/hexenmeister/MyFHEM/blob/master/killfhem.sh
https://github.com/hexenmeister/MyFHEM/blob/master/runfhem.sh

gestoßen !? und habe diese auch ins Hauptverzeichnis von Fhem geschoben .

Die reine Fhemseite scheint nun fehlerfrei zu laufen !!!
Der Sägezahnplot funktioniert ...

Zum Verständnis hätte ich hier die erste Frage :
In der Fhem.config

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]

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

LG

pah

[Aladin222]

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]

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]

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]

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 !?