Fhem aus Raspi: alle 90 Sekunden ein shutdown / restart

Begonnen von Rainer_G, 05 Oktober 2021, 00:01:21

Vorheriges Thema - Nächstes Thema

Rainer_G

ok, ich hab jetzt mal freezemon in meiner fhem.cfg definiert.
Mal schauen, was das aufläuft .....

betateilchen

Zitat von: Rainer_G am 08 Oktober 2021, 23:55:00
Wie und wo setzte ich denn die PIDFile Option ein ?

Lass das bitte sein.

Mach mal bitte ein "list global" und poste die Ausgabe.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Rainer_G

#17
Hallo Betateilchen,
hier ist der "list global" output:

Internals:
   DEF        no definition
   FD         3
   NAME       global
   NR         1
   STATE      no definition
   TYPE       Global
   currentlogfile ./log/fhem-2021-10.log
   logfile    -
Attributes:
   autoload_undefined_devices 1
   autosave   1
   configfile fhem.cfg
   logfile    ./log/fhem-%Y-%m.log
   modpath    .
   motd       none
   userattr   FS20 FS20_map cmdIcon devStateIcon:textField-long devStateStyle icon sortby structexclude webCmd webCmdLabel:textField-long widgetOverride
   verbose    3
   version    fhem.pl:22408/2020-07-16

betateilchen

Bitte verwende das nächste Mal die Code-Tags zum Posten solcher Daten. Danke.

Das Verhalten Deines Raspi rührt daher, dass FHEM den eigenen Prozess beim Start nicht korrekt forken kann. Deshalb war meine Hoffnung, in Deiner globalen Konfiguration einen Hinweis auf die Ursache zu finden. Aber da gibt es keine Hinweise.

Versuche mal bitte Folgendes:


  • beende FHEM über den Service (service fhem stop)
  • starte als root auf der Systemkonsole fhem manuell (im Verzeichnis /opt/fhem mit "perl fhem.pl fhem.cfg" aufrufen)
  • Beobachte, ob FHEM nach 90 Sekunden abstürzt

Die Ursache für Dein Problem vermute ich inzwischen eher auf Deinem Raspi, nicht in Deinem FHEM.
(User, Rechte, Speicher, irgendwas in der Richtung)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Wernieman

- 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

Rainer_G

Hallo betateilchen,

ok, habe ich gemacht, aber nachdem ich fhem so gestartet habe:
root@raspberrypi:/opt/fhem# service fhem stop
root@raspberrypi:/opt/fhem# perl fhem.pl fhem.cfg
2021.10.12 21:02:27 1: Including fhem.cfg

läuft es ebenfalls solange, bis ich es in der Konsole oder in der Fhem GUI wieder stoppe (über 90 sec hinaus).

@Wernieman: Die SD Karte hatte ich auch schon in Verdacht, aber eine andere verhält sich hier genauso.


Rainer_G

Ich werde demnächst mal einen anderen Raspi testen.
Einfach um die HW auszuschließen.

Rainer_G

Ich habe gerade mal meinen alten Raspi Model 8 V1.2 reaktiviert (noch kein WLAN).
Das Vehalten ist hier exakt das gleiche.
Sobald ich im fhem.system Type=forking setzte, startet Fhem alles 90 Sekunden neu.
Setzte ich Type=simple, ist das Problem behoben und Fehm läuft durch.

Damit wäre der Raspi wohl raus.
Bleiben nur noch die beiden CUL Sticks, die ich hier aber mal ausschließe, da alle Signale an meine FHTs und FS20s sauber durchkommen.

Rainer_G

Hallo Otto123,

hier ist übrigens mal ein kurzer Auszug meines freezemon logs:
2021-10-12_21:40:00 myFreezes s:21:39:55 e:21:40:00 f:5.66 d:no bad guy found :-(
2021-10-12_21:40:00 myFreezes freezeTime: 5.66
2021-10-12_21:40:00 myFreezes fcDay: 3
2021-10-12_21:40:00 myFreezes ftDay: 12.667
2021-10-12_21:40:00 myFreezes freezeDevice: no bad guy found :-(
2021-10-12_21:41:16 myFreezes s:21:41:12 e:21:41:16 f:4.912 d:no bad guy found :-(
2021-10-12_21:41:16 myFreezes freezeTime: 4.912
2021-10-12_21:41:16 myFreezes fcDay: 1
2021-10-12_21:41:16 myFreezes ftDay: 4.912
2021-10-12_21:41:16 myFreezes freezeDevice: no bad guy found :-(
2021-10-12_21:41:19 myFreezes s:21:41:17 e:21:41:19 f:2.794 d:tmr-CUL_HandleWriteQueue(CUL_0) tmr-CUL_HM_updateConfig(N/A) tmr-CUL_HM_procQs(N/A)
2021-10-12_21:41:19 myFreezes freezeTime: 2.794
2021-10-12_21:41:19 myFreezes fcDay: 2
2021-10-12_21:41:19 myFreezes ftDay: 7.706
2021-10-12_21:41:19 myFreezes freezeDevice: tmr-CUL_HandleWriteQueue(CUL_0) tmr-CUL_HM_updateConfig(N/A) tmr-CUL_HM_procQs(N/A)
2021-10-12_21:42:43 myFreezes s:21:42:42 e:21:42:43 f:1.657 d:no bad guy found :-(
2021-10-12_21:42:43 myFreezes freezeTime: 1.657
2021-10-12_21:42:43 myFreezes fcDay: 1
2021-10-12_21:42:43 myFreezes ftDay: 1.657
2021-10-12_21:42:43 myFreezes freezeDevice: no bad guy found :-(
2021-10-12_21:42:46 myFreezes s:21:42:44 e:21:42:46 f:2.256 d:tmr-CUL_HM_updateConfig(N/A)
2021-10-12_21:42:46 myFreezes freezeTime: 2.256
2021-10-12_21:42:46 myFreezes fcDay: 2
2021-10-12_21:42:46 myFreezes ftDay: 3.913
2021-10-12_21:42:46 myFreezes freezeDevice: tmr-CUL_HM_updateConfig(N/A)
2021-10-12_21:42:48 myFreezes s:21:42:47 e:21:42:48 f:1.954 d:tmr-CUL_HM_procQs(N/A)
2021-10-12_21:42:48 myFreezes freezeTime: 1.954
2021-10-12_21:42:48 myFreezes fcDay: 3
2021-10-12_21:42:48 myFreezes ftDay: 5.867
2021-10-12_21:42:48 myFreezes freezeDevice: tmr-CUL_HM_procQs(N/A)
2021-10-12_21:44:19 myFreezes s:21:44:13 e:21:44:19 f:6.691 d:no bad guy found :-(
2021-10-12_21:44:19 myFreezes freezeTime: 6.691
2021-10-12_21:44:19 myFreezes fcDay: 1
2021-10-12_21:44:19 myFreezes ftDay: 6.691
2021-10-12_21:44:19 myFreezes freezeDevice: no bad guy found :-(
2021-10-12_21:44:22 myFreezes s:21:44:20 e:21:44:22 f:2.653 d:tmr-CUL_HM_updateConfig(N/A) tmr-CUL_HM_procQs(N/A) tmr-CUL_HandleWriteQueue(CUL_0)
2021-10-12_21:44:22 myFreezes freezeTime: 2.653
2021-10-12_21:44:22 myFreezes fcDay: 2
2021-10-12_21:44:22 myFreezes ftDay: 9.344
2021-10-12_21:44:22 myFreezes freezeDevice: tmr-CUL_HM_updateConfig(N/A) tmr-CUL_HM_procQs(N/A) tmr-CUL_HandleWriteQueue(CUL_0)
2021-10-12_21:45:49 myFreezes s:21:45:44 e:21:45:49 f:5.53 d:no bad guy found :-(
2021-10-12_21:45:49 myFreezes freezeTime: 5.53
2021-10-12_21:45:49 myFreezes fcDay: 1
2021-10-12_21:45:49 myFreezes ftDay: 5.53
2021-10-12_21:45:49 myFreezes freezeDevice: no bad guy found :-(
2021-10-12_21:45:52 myFreezes s:21:45:50 e:21:45:52 f:2.132 d:tmr-CUL_HM_updateConfig(N/A) tmr-CUL_HM_procQs(N/A)
2021-10-12_21:45:52 myFreezes freezeTime: 2.132
2021-10-12_21:45:52 myFreezes fcDay: 2
2021-10-12_21:45:52 myFreezes ftDay: 7.662
2021-10-12_21:45:52 myFreezes freezeDevice: tmr-CUL_HM_updateConfig(N/A) tmr-CUL_HM_procQs(N/A)
2021-10-12_21:54:58 myFreezes s:21:39:00 e:21:54:58 f:958.495 d:no bad guy found :-(
2021-10-12_21:54:58 myFreezes freezeTime: 958.495
2021-10-12_21:54:58 myFreezes fcDay: 1
2021-10-12_21:54:58 myFreezes ftDay: 958.495
2021-10-12_21:54:58 myFreezes freezeDevice: no bad guy found :-(

Ich kann hier aber nicht wirklich was herauslesen.

Wernieman

2021-10-12_21:54:58 myFreezes freezeTime: 958.495

Wobei solche Freeze genau dazu führen, das FHEM nicht reagiert und deshalb systemd davon ausgeht, das es nicht läuft und es rebootet .....
- 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

KölnSolar

Stimmt. Aber über 15' suggeriert mir etwas anderes. Vielleicht nach einem reboot u. die Zeit noch nicht neu gesetzt(zu Beginn des vermeintlichen freezes) ?  :-\

Auf jeden Fall mal das freezemon-logging aktivieren(siehe commandref). Denn auch die "kleinen" freezes sehen nicht gerade "gesund" aus. Und immer wieder CUL_HM. Hab ich aber keine Ahnung von. :'(

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Beta-User

Und gibt es einen speziellen Grund, warum man bei vorhandenen Problemen kein update macht? fhem.pl ist aus 2020...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Rainer_G

Hallo Beta-User,
davon ausgehend, dass in der Fhem Konsole der Befehl update ein Update durchführt, habe ich fhem in den letzten 3 Wochen der Fehlersuche bestimmt schon 20 mal upgedatet.
Ich habe es auch mehrere mal komplett deinstalliert und neu vom Server geholt.
Möglicherweise habe ich dabei etwas falsch gemacht.
Nicht jeder hat jahrelange Linux Erfahrung  ;)

Rainer_G

Hallo Beta-User,
ja, Dein Tipp war der entscheidende. Offenbar habe ich wirklich beim updaten Fehler gemacht.
Hab jetzt alles nochmal glatt gebügelt und neu installiert und denke jetzt auf dem neusten Stand zu sein:
version fhem
fhem.pl 25039 2021-10-01 16:21:46Z rudolfkoenig

Jetzt läuft Fhem trotz Type=forking einwandfrei durch !!!

Otto 123, Betateilchen, Beta-User, Wernieman,
vielen Dank für Eure Hilfe !!
Ich habe viel gelernt  ;D
Diese Forum ist wirklich hilfreich !


Rainer_G

Hallo KölnSolar,

jetzt würde mich doch noch interessieren, wie ich das freezmon logging aktiviere.
Meine bisherige definition im fhem.cfg schaut so aus:
    define myFreezes freezemon
attr myFreezes room Wartung

define myFreezesLog FileLog ./log/myFreezes-%Y.log myFreezes
attr myFreezesLog logtype text
attr myFreezesLog room Logs

In der commandref habe ich u.a. folgendes Attribut gefunden:
fm_log: dynamic loglevel, takes a string like 10:1 5:2 1:3 , which means: freezes > 10 seconds will be logged with loglevel 1 , >5 seconds with loglevel 2 etc...

Meinst Du das ?