RPI cronjob fhem Status und fhem start

Begonnen von jnewton957, 27 April 2017, 20:20:56

Vorheriges Thema - Nächstes Thema

jnewton957

Hallo,

ich habe seit einigen Tagen häufiger einen Ausfall den Fhem. Das merke ich aber erst abends und habe so unter Tage keine Strommessdaten bzw. Ausfall der Haussteuerung.

Ich starte dann einfach direkt auf der RPI den Fenstern Fhem wieder und es klappt für die nächsten Stunden.
Im log steht nichts dazu. Update ist gemacht.
Da ich gerade keine Zeit für weitere/tiefere Ursachenforschung habe -nachfolgende Frage:

Hat jemand für mich eine Idee bzw. Direkt den Cronjob der z.B stündlich nachschaut, ob fhem noch läuft und dann ggf. automatisch fhem wieder atartet.

Danke für die Hilfe
Jörg
FHEM6.2 auf Pi5
V 1.66 nanoCUL 433 (IT)
V 1.66 nanoCUL868 (HM)
sqlite3 LogDb
ELRO AB440, DECT200,  TFA30.3125, esp8266, HM, TabletUI, IR-Schreiblesekopf (Udo),tibber Pulse, Kostal Pico, cfos Wallbox, Modbus TCP

P.A.Trick

Das folgende Skript unter /root/scripts anlegen


#!/bin/sh

result=$(ps -ef | grep fhem.pl | egrep -v grep|wc -l)

if [ $result -gt 0 ]
then
        echo "+++ Fhem is up and running -> OK! +++" >&1
else
        echo "--- fhem is down ($result) ---" >&2
  /etc/init.d/fhem start
fi




Aufgerufen in der root-Crontab wie folgt:

# Pruefen ob FHEM laeuft
*/6 * * * * /root/scripts/check_fhem.sh 1>/dev/null


Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

jnewton957

Ganz vielen Dank.

Wenige Minuten Implementierung und riesen Wirkung.

Das sollte eigentlich auch ins Wiki !??

Jörg
FHEM6.2 auf Pi5
V 1.66 nanoCUL 433 (IT)
V 1.66 nanoCUL868 (HM)
sqlite3 LogDb
ELRO AB440, DECT200,  TFA30.3125, esp8266, HM, TabletUI, IR-Schreiblesekopf (Udo),tibber Pulse, Kostal Pico, cfos Wallbox, Modbus TCP

DeeSPe

Zitat von: jnewton957 am 28 April 2017, 07:40:04
Das sollte eigentlich auch ins Wiki !??

Nein, denn das ist keine adäquate Problemlösung.
Es sollten lieber die Ursachen ergründet und der/die Fehler beseitigt werden.
Ein Linux Host sollte nur neu gestartet werden wenn es wirklich nötig ist (z.B. Kernel Update).

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

jnewton957

Zitat von: DeeSPe am 28 April 2017, 07:45:17
Nein, denn das ist keine adäquate Problemlösung.
Es sollten lieber die Ursachen ergründet und der/die Fehler beseitigt werden.
Ein Linux Host sollte nur neu gestartet werden wenn es wirklich nötig ist (z.B. Kernel Update).

Gruß
Dan

Da gebe ich dir natürlich Recht. Ds ist kein "Allheilmittel". Aber eben genau mit DEINEM Hinweis könnte man es ja eintragen.
FHEM6.2 auf Pi5
V 1.66 nanoCUL 433 (IT)
V 1.66 nanoCUL868 (HM)
sqlite3 LogDb
ELRO AB440, DECT200,  TFA30.3125, esp8266, HM, TabletUI, IR-Schreiblesekopf (Udo),tibber Pulse, Kostal Pico, cfos Wallbox, Modbus TCP

kumue

Zitat von: DeeSPe am 28 April 2017, 07:45:17
Nein, denn das ist keine adäquate Problemlösung.
Es sollten lieber die Ursachen ergründet und der/die Fehler beseitigt werden.
Ein Linux Host sollte nur neu gestartet werden wenn es wirklich nötig ist (z.B. Kernel Update).

Gruß
Dan

Klar, Ursachenforschung sollte natürlich getrieben werden. Da gibt Dir jeder Recht.
Aber das Script startet doch "nur" den Dienst neu...

CoolTux

#6
Das Script funktioniert nicht wenn FHEM hängt aber der Prozess dennoch in der Prozesstabelle steht. Zu mindest ein Test auf Zombi hätte man noch machen können.
Besser wäre ein versuchter telnet Aufruf auf 7072 und diesen auswerten. Das kann man mit einem kleinen Perlscript machen  ;D

Zweite Variante. Hier im Forum nach watchdog suchen in Verbindung mit betateilchen. Udo lässt alle eine Minute über FHEM at eine Datei schreiben und wertet den Zeitstempel mit einem watchdog Programm aus. Ist der Zeitstempel zu alt wird das system neu gestartet.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Wernieman

Trotzdem sollte FHEM nicht einfach "weg" sein.

Außerdem würde ich das starten von FHEM mitloggen, Ohne Logfile ist ein Debugging nicht möglich.

NUr folgenden Satz verstehe ich aktuell nicht
ZitatRPI den Fenstern Fhem
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Stargazer

Ich hatte das gleiche Problem, mit FHEM.

Zuerst auf einem RasPi, wo ich dachte, es läge an der SD-Karte. Doch tauchte es auch in meiner neuen VM nach ca. 2 Wochen auf. Ich habe zwei FHEM Instanzen per FHEM2FHEM verbunden (Hausserver zu Energieserver). Zudem hatte ich eine Überwachung drin, falls diese Verbindung Mal wegbrechen sollte.

Als das FHEM Problem nun wieder auftauchte, habe ich diese Überwachung wieder gelöscht und auch ein paar alte Logs auf dem betroffenen System gelöscht. Und seit dem läuft alles wieder stabil. Obwohl ein Konsolenaufruf zur Speicherstadting unauffälliges zeigte.

Vielleicht hilft es dir ja.

VG

André