Fhem aus Raspi: alle 90 Sekunden ein shutdown / restart

[Rainer_G]

Vor ca. 3 Wochen begann sich der Fhem Server auf meinem Raspi alle 90 Sekunden zu zurückzusetzen.
Aus dem log war die Ursache nicht zu entnehmen.
Die Events kurz vor den Server shutdown sind zufällig und scheinen mit dem shutdown nicht zusammen zu hängen.

2021.10.04 23:42:27 0: Server shutdown
2021.10.04 23:42:28 1: Shutdown executed
2021.10.04 23:42:28 3: telnetPort: port 7072 opened
2021.10.04 23:42:29 3: WEB: port 8083 opened
2021.10.04 23:42:29 3: WEBphone: port 8084 opened
2021.10.04 23:42:29 3: WEBtablet: port 8085 opened
2021.10.04 23:42:29 3: WEB: creating device allowed_WEB for attribute basicAuth WEBphone: creating device allowed_WEBphone for attribute basicAuth WEBtablet: creating device allowed_WEBtablet for attribute basicAuth
2021.10.04 23:42:29 3: Opening CUL_1 device /dev/ttyACM1
2021.10.04 23:42:29 3: Setting CUL_1 serial parameters to 38400,8,N,1
2021.10.04 23:42:30 3: CUL_1: Possible commands: ABbCeFGhiKkLlMmNRTtUuVWXxYZ
2021.10.04 23:42:30 3: CUL_1 device opened
2021.10.04 23:42:30 2: Switched CUL_1 rfmode to HomeMatic
2021.10.04 23:42:30 3: Opening CUL_0 device /dev/ttyACM0
2021.10.04 23:42:30 3: Setting CUL_0 serial parameters to 38400,8,N,1
2021.10.04 23:42:30 3: CUL_0: Possible commands: BbCFiAZNkGMKUYRTVWXefmLltux
2021.10.04 23:42:30 3: CUL_0 device opened
2021.10.04 23:42:30 2: eventTypes: loaded 769 events from ./log/eventTypes.txt
2021.10.04 23:42:31 1: PERL WARNING: Use of uninitialized value $m in int at ./FHEM/10_CUL_HM.pm line 9373.
2021.10.04 23:42:31 3: Device broadcast added to ActionDetector with 030:00 time
2021.10.04 23:42:31 3: Device kiHeater added to ActionDetector with 000:10 time
2021.10.04 23:42:31 3: Device ubHeater added to ActionDetector with 000:10 time
2021.10.04 23:42:31 3: WARNING master device kiHeater_Clima has no week profile - create default
2021.10.04 23:42:31 3: Opening myBroker device 127.0.0.1:1883
2021.10.04 23:42:31 3: myBroker device opened
2021.10.04 23:42:31 3: WARNING master device ubHeater_Clima has no week profile - create default
2021.10.04 23:42:31 0: Featurelevel: 6
2021.10.04 23:42:31 0: Server started with 214 defined entities (fhem.pl:22408/2020-07-16 perl:5.028001 os:linux user:fhem pid:15319)
2021.10.04 23:42:45 3: CUL_HM set kiHeater getConfig
2021.10.04 23:42:45 3: WARNING master device kiHeater_Clima has no week profile - create default
2021.10.04 23:43:58 0: Server shutdown
2021.10.04 23:43:58 1: Shutdown executed

Es scheint asynchron zu den irgendwelchen Aktivitäten im Fhem zu passieren.
Gibt es eine systematische Methode, die Ursache hierfür herauszufinden ?
Der Raspi läuft vollkommen stabil.
Diese Fhem Konfiguration lieft bis vor 3 Wochen ebenfalls stabil.
Es laufen keinerlei Chron Jobs auf dem Raspi.

Mein Config:
1 CUL Stick für das FS20 Protokoll ( 3 FHT 80 B)
1 CUL Stick für Homeatic ( 2 x HM-CC-RT-DN )
MQTT Broker ( viele Sonoff Schalter )

Sowohl Fhem, als auch das Raspi OS sind auf dem neusten Stand.

Die Hinweise in einem gleichlautenden Thread habe ich alle schon ausprobiert.
Ich wäre für jeden Tipp dankbar !!!

[Beta-User]

Würde auf systemd tippen, der nicht mitbekommt, dass FHEM stressfrei läuft und glaubt, dass es abgeschmiert ist. Wie ist denn der restart-timeout in der fhem.service?

[Otto123]

Siehe auch hier https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)#Restart_verz.C3.B6gern

Aber 90 sec ? Das kann kein Zufall sein. Da läuft entweder ein watchdog oder oder etwas blockiert solange?
Zumal er schmiert nicht ab, er macht ordentlich shutdown 

[betateilchen]

Würde auf systemd tippen, der nicht mitbekommt, dass FHEM stressfrei läuft

Hinweise darauf würde man zumindest im syslog finden.

[Rainer_G]

Hallo Beta-User, Otto123 und betateilchen,
vielen Dank für die schnellen Antworten.
Dass die 90 Sekunden auf einen nicht getriggerten Watchdog hinweisen kam mir auch schon in den Sinn.
Leider kenne ich Linux zu wenig, um zu wissen, welcher WD von Fehm möglicherweise nicht getriggert wird.
Jetzt meine Anfänger Fragen:
@Beta-User: Wie teilt Fhem systemd mit, dass es stressfrei läuft ?
@betateilchen: Wo finde ich das syslog ?

Ich habe auch schon versucht, Fhem neu zu installieren, wonach der 90 sekündige reset tatsächlich ausbleibt.
Dann habe ich mein fhem.cfg sukkzessive auskommentiert, um evtl. das device einzukreisen, das das Problem verursacht.
Ebenfalls habe ich festgestellt, dass es einen Unterschied macht, ob ich fhem.cfg via FTP auf meinen Raspi kopiere, oder via Fhem GUI mit Copy/Paste einfüge.

Aber einen eindeutigen fhem.cfg Zustand, ab dem der zyklische Reset ausbleibt, ließ sich bisher nicht ausmachen.
Das spricht dafür, dass das OS von Außen Fhem immer wieder neu startet.

Ich probiere mittlerweile seit Wochen mit trial und error herum und möchte nun stattdessen auf diesem Wege
von Euch Experten ein bischen mehr über Linux lernen und so dem Problem systematisch zu Leibe rücken.

Es ist sehr schwierig, via Google hier die wertvolle Info aus dem Strom von weniger zielführenden Kommentaren herauszufiltern.
Im Voraus vielen Dank für jede Form der Hilfestellung !

[Beta-User]

Linux-Konsole. Habe aber kein RaspiOS, bei Debian zeigt z.B.

Code Auswählen Erweitern

sudo grep fhem /var/log/syslog
an, was über "fhem" im heutigen syslog steht. Steht in der Datei nichts, wurde FHEM jedenfalls nicht von systemd neu gestartet.

cfg-Editieren ist "Bäh" und möglicherweise mit die Ursache für dein Problem. Am besten mit "leerer" fhem.cfg (also der svn-Version) starten und dann über das Web-Frontend (das "grüne Plus") dazubauen. Nur CUL_HM-Geräte (und vorher die zugehörigen Interfaces sollte man per direktem Edit in der cfg lassen. Dazu bitte aber am besten einen Linux-kompatiblen Editor nutzen. Meine Empfehlung: via ssh mc nutzen.

[Wernieman]

Du kannst doch Gerät auch über "Raw" in die fhem.cfg pushen?

[betateilchen]

Habe aber kein RaspiOS, bei Debian zeigt z.B.

RaspiOS basiert auf Debian und hieß früher deshalb auch Raspbian.

Nach Einträgen von systemd sollte man auch in /var/log/daemon.log suchen, falls in /var/log/syslog nichts zu finden ist.

[Rainer_G]

Hallo Betateilchen,
vielen Dank für den Tipp !
War leider die letzten Tage verhindert und kann jetzt erst antworten.
Das Kommando
root@raspberrypi:/opt# grep fhem /var/log/syslog   
zeigt, dass fhem tatsächlich in ein Start Timeout läuft und den service terminiert.

Hier nur ein kleiner Ausschnitt der sich im 90 sekündigen Takt wiederholenden 5 Zeilen:

Oct  8 19:58:37 raspberrypi perl[15429]: 2021.10.08 19:58:37 1: Including fhem.cfg
Oct  8 20:00:07 raspberrypi systemd[1]: fhem.service: Start operation timed out. Terminating.
Oct  8 20:00:07 raspberrypi systemd[1]: fhem.service: Failed with result 'timeout'.
Oct  8 20:00:07 raspberrypi systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Oct  8 20:00:07 raspberrypi systemd[1]: fhem.service: Scheduled restart job, restart counter is at 7440.
Oct  8 20:00:08 raspberrypi perl[15467]: 2021.10.08 20:00:08 1: Including fhem.cfg
Oct  8 20:01:37 raspberrypi systemd[1]: fhem.service: Start operation timed out. Terminating.
Oct  8 20:01:38 raspberrypi systemd[1]: fhem.service: Failed with result 'timeout'.
Oct  8 20:01:38 raspberrypi systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Oct  8 20:01:38 raspberrypi systemd[1]: fhem.service: Scheduled restart job, restart counter is at 7441.
Oct  8 20:01:38 raspberrypi perl[15474]: 2021.10.08 20:01:38 1: Including fhem.cfg
Oct  8 20:03:08 raspberrypi systemd[1]: fhem.service: Start operation timed out. Terminating.
Oct  8 20:03:08 raspberrypi systemd[1]: fhem.service: Failed with result 'timeout'.
Oct  8 20:03:08 raspberrypi systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Oct  8 20:03:08 raspberrypi systemd[1]: fhem.service: Scheduled restart job, restart counter is at 7442.
Oct  8 20:03:09 raspberrypi perl[15523]: 2021.10.08 20:03:09 1: Including fhem.cfg
Oct  8 20:04:38 raspberrypi systemd[1]: fhem.service: Start operation timed out. Terminating.
Oct  8 20:04:39 raspberrypi systemd[1]: fhem.service: Failed with result 'timeout'.
Oct  8 20:04:39 raspberrypi systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Oct  8 20:04:39 raspberrypi systemd[1]: fhem.service: Scheduled restart job, restart counter is at 7443.
Oct  8 20:04:39 raspberrypi perl[15534]: 2021.10.08 20:04:39 1: Including fhem.cfg
Oct  8 20:06:09 raspberrypi systemd[1]: fhem.service: Start operation timed out. Terminating.
Oct  8 20:06:09 raspberrypi systemd[1]: fhem.service: Failed with result 'timeout'.
Oct  8 20:06:09 raspberrypi systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Oct  8 20:06:09 raspberrypi systemd[1]: fhem.service: Scheduled restart job, restart counter is at 7444.
Oct  8 20:06:10 raspberrypi perl[15544]: 2021.10.08 20:06:10 1: Including fhem.cfg
Oct  8 20:07:39 raspberrypi systemd[1]: fhem.service: Start operation timed out. Terminating.
Oct  8 20:07:40 raspberrypi systemd[1]: fhem.service: Failed with result 'timeout'.
Oct  8 20:07:40 raspberrypi systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Oct  8 20:07:40 raspberrypi systemd[1]: fhem.service: Scheduled restart job, restart counter is at 7445.
Oct  8 20:07:40 raspberrypi perl[15562]: 2021.10.08 20:07:40 1: Including fhem.cfg

Die Frage ist jetzt nur: Womit kann ich den Timeout wieder aufziehen ?
Soll ich mein fhem.cfg mal posten ?
Ist ziemlich länglich 

[Rainer_G]

PS:
grep fhem /var/log/daemon.log
klappt auch, zeigt aber das gleiche an.

[Rainer_G]

Ich habe jetzt mal gemäss anderer Tipps in anderen Chats in der Fhem service config den Parameter Type von forking auf simple umgestellt:

Kommando: sudo systemctl edit --full fhem.service

File Inhalt:


# $Id: fhem.service 19235 2019-04-21 13:26:17Z betateilchen $

[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target
#Requires=postgresql.service
#After=postgresql.service
#Requires=mysql.service
#After=mysql.service

[Service]
Type=simple (vorher forking)
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
Restart=always
ExecStartPre=/bin/sleep 10

[Install]
WantedBy=multi-user.target


Jetzt läuft Fhem wieder durch !!!!

Frage: Was bedeutet Type=forking ?

[Otto123]

Hi,

kannst Du hier nachlesen:
https://www.freedesktop.org/software/systemd/man/systemd.service.html

Das ist aber schon nicht die Original unit Datei, da hast Du schon eine Verzögerung eingebaut. Was war der Grund?

Gruß Otto

[Rainer_G]

Hi Otto123,

danke für den Hinweis !
Stimmt, hab ich vergessen wieder auszukommentieren.
Ich probiere alles aus, was ich in diversen chats so finde.
Das war einer von vielen Tipps.

Ich habs gerade wieder auskommentiert und Fhem läuft immer noch rund 

[Rainer_G]

ich hab mir Deinen Link mal durchgelesen und folgendes gefunden (rot):


Configures the process start-up type for this service unit. One of simple, exec, forking, oneshot, dbus, notify or idle:
.....
If set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main service process, and the service manager will consider the unit started when the parent process exits. This is the behavior of traditional UNIX services. If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can reliably identify the main process of the service. systemd will proceed with starting follow-up units as soon as the parent process exits.


Wie und wo setzte ich denn die PIDFile Option ein ?
Welchen der obigen Type values würdest Du denn empfehlen und warum ?

Übrigens, danke für Deine Hilfe !!!!

[Otto123]

Moin,

tut mir leid, damit habe ich mich noch nicht beschäftigt. Bisher habe ich nur mit diversen Verzögerungen, Abhängigkeit von anderen Diensten und dem Start von "Vorbereitungen für bestimmte Hardware" von FHEM befasst und das hier im Wiki aufgeschrieben.
Vielleicht kann betateilchen was dazu sagen, der hat den systemd Startprozess von FHEM designed.
Ich habe keine Idee woher die 90 sec kommen. Jetzt wo FHEM durchläuft könntest Du mal freezemon definieren und schauen ob da was passiert.

Gruß Otto

[Rainer_G]

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

[betateilchen]

Wie und wo setzte ich denn die PIDFile Option ein ?

Lass das bitte sein.

Mach mal bitte ein "list global" und poste die Ausgabe.

[Rainer_G]

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)

[Wernieman]

Oder eventuell sogar die SD-Card ....

[Rainer_G]

Hallo betateilchen,

ok, habe ich gemacht, aber nachdem ich fhem so gestartet habe:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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]

Code Auswählen Erweitern

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 .....

[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

[Beta-User]

Und gibt es einen speziellen Grund, warum man bei vorhandenen Problemen kein update macht? fhem.pl ist aus 2020...

[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:

Code Auswählen Erweitern

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 
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:

Code Auswählen Erweitern

    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:

Code Auswählen Erweitern

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 ?

[Rainer_G]

Zu früh gefreut !
Nach dem ich bei dem frisch installierten Fehm die default fhem.cfg gegen meine eigene ausgetauscht hatte, lief Fhem noch über die 90 Sekunden hinaus (auch mit Type=forking).
Danach habe ich das 11_FHT.pm mit meinem modifizierten überschrieben.
Dieses berücksichtigt noch einige Features eines Selbstbebauten, Arduino-basierten Rechners.
Danach wieder Reset alle 90 Sekunden.

Jetzt dachte ich, dass es wohl an meiner 11_FHT.pm Modifikation liegen muss.
Nun wieder das original via SFTP zurückgespielt => immernoch Reset alle 90 Sek.

Vielleicht liegt es an einer Modifikation, die SFTP mit dem File gemacht hat.
Also 11_FHT.pm via ZOC / Terminal gelöscht und via update wieder das original restauriert => immernoch Reset ...

Vielleicht liegt es an den modifizierten Zugriffsrechten im FHEM Verzeichnis.
Also von 777 wieder auf 644 zurückgestellt => immernoch Reset ....

Erst ein Type==simple in fhem.system hat das Problem wieder behoben.

Bin also wieder am Anfang, auch wenn ich mit diesem Zustand gut leben kann.
Trotzdem würde mich die Ursache interessieren.

[Beta-User]

Ganz ehrlich: Für meine Begriffe passen da Kenntnisse und Aktivitäten nicht wirklich zusammen, und auch die Offenheit, was und welche Modifikationen da wo vorgenommen wurden, läßt zumindest bei der ersten Problembeschreibung etwas zu wünschen übrig...

Wer sein System so verbiegt, sollte schon wissen, was er da tut .

[Rainer_G]

@Beta-User: Dein letzter Kommentar war schon ähnlich latent herablassend.
Wenn Du so allwissend bist, könntest Du mir ja einfach sagen, woran es liegt oder mir wenigstens konstruktive Tipps geben.
Solche Foren sollten ja dafür da sein, damit Dummies wie ich von Göttern wie Dir etwas lernen können, oder

[Beta-User]

a) ich bin nicht allwissend.
b) an sich helfe ich gerne
c) ich werfe auch schon mal die Glaskugel an und lande den einen oder anderen Treffer. Das bedeutet aber nicht, dass a) falsch wäre und ich nicht das eine oder andere Mal eine Suchmaschine benötigen würde oder eine manpage.

Also mal weg von den tonalen Fragen:
- Du lieferst wenig Info.
- Wir stellen irgendwann fest, dass fhem.pl recht alt ist und empfehlen ein update
- Du installierst neu, update läuft durch, alles läuft scheinbar (1)

Dann vollziehst du irgendwelche Änderungen (vermutlich dein "Standardset"), verrätst aber nebenbei nur einen Teil dessen, was du gemacht hast (?), und stellst fest, dass es wieder nicht läuft (2).

Daraus würde ich den Schluss ziehen, dass entweder (1) nicht zutreffend war, oder (irgendwas in) (2) dazu geführt hat, dass du vor immer wieder demselben Problem stehst. Das ist frustrierend für dich und suboptimal für uns, weil wir eigentlich nur mit (1) helfen können und ggf. Tipps geben für (2), wenn wir wissen, was du da GENAU tust und warum (dann können wir vielleicht Alternativen aufzeigen).

Mein Tipp wäre also, erst mal bei (1) zu bleiben und abzusichern, dass FHEM wirklich in einem Standard durchläuft.

Und dann DETAILLIERT durchzugehen, was man von (2) wirklich wie benötigt...

Als erste Tipps zu (2) würde ich zum einen vorschlagen, dass du administrative Aufgaben auf dem Pi und das Editieren von Dateien direkt mit einer ssh-shell erledigst und dazu ggf. einen anderen Editor nutzt als nano. Würde mcedit aus dem Paket mc empfehlen. Von pauschalen Änderungen der Dateirechte sollte man mAn. die Finger lassen!
Zum anderen solltest du mal checken, wie jetzt die Dateirechte sind, unter /opt/fhem sollte eigentlich alles fhem:dialout gehören ("ls -l" - ausgeführt an der richtigen Stelle - gäbe jeweils Antwort).

[KölnSolar]

jetzt würde mich doch noch interessieren, wie ich das freezmon logging aktiviere

mit

Code Auswählen Erweitern

attr myFreezes fm_logFile ./log/freeze-%Y%m%d.log

[Rainer_G]

@KölnSolar: Danke, werde ich gleich mal probieren.

[Rainer_G]

Hallo Beta-User,

vielen Dank für Deine umfangreiche Antwort.
Bisher habe ich jede Info, die Ihr angefordert habt auch prompt geliefert.
Ich versuche mein Problem so transparent wie möglich zu beschreiben.
Für mich ist Fhem und Linux noch ein Landkarte mit vielen weißen Flecken.
Allein der Datenaustausch zwischen Fhem und dem OS ist mir ein Buch mit 7 Siegeln.
Einiges habt Ihr mir ja schon offenbart.
Natürlich google ich wie der Teufel und versucht meine Problem selbst zu lösen, aber hier war ich mit meinem Latein am Ende, wie auch einige andere mit dem gleichen Problem.
Alle Feeds zu diesem Thema verlaufen irgendwo im Sande oder zweigen thematisch an stellen ab, die für mich nicht mehr relevant sind.
Bisher bin ich lediglich Fhem User und habe alles mit diversen Code Snippets aus dem Netz zum laufen gebracht.
Aber um hier weiterzukommen, benötige ich tieferes System-Wissen, was ich im Dialog mit Euch Experten zu erlangen hoffte.

Klar liegt es auf der Hand, dass das Problem in meiner "verbogenen" Konfiguration liegt.
Aber wenn ich alles wieder auf einen Zustand zurückversetzte, in dem es vorher einwandfrei lief und das Problem damit aber nicht verschwindet,
dann beginne ich über Nebensächlichkeiten zu berichten, die eigentlich keine Relevanz haben sollten (geänderte Zugriffsrechte etc.).
Wäre ja möglich, dass es bei Fhem ein security feature ist und es bei geänderten Rechten so reagiert !?

Zusammenfassend scheint der OS Watchdog, den Fhem regelmäßig wieder aufziehen muss, durch eine banale Maßnahme nicht mehr von Fhem bedient zu werden.
Denn diese 90 Sekunden Reset Intervall findet man in einigen Feeds hier im Forum.
Damit wäre dann meine individuelle fhem.cfg raus, bzw. enthält etwas oder lässt etwas vermissen, was bei mehreren Usern zuschlägt.

Da ich in keinem dieser Feeds eine zufriedenstellende Lösung gefunden habe und aber mit dieser möglicherweise unsauberen aber funktionierenden Lösung leben kann (Type=simple (statt forking)),
belasse ich es jetzt vorerst mal dabei, lasse den Feed aber offen.
Vielleicht stolpert ja eines Tages ein betroffener User darüber und präsentiert hier eine Lösung 

[betateilchen]

Setz doch mal auf einer neuen SD-Karte ein neues, leeres FHEM auf und teste, ob das Problem dann immer noch besteht. Dazu verwendest Du am besten direkt eine aktuelle Version von FHEM, z.B. das nightly-Build von https://debian.fhem.de, dann sparst Du Dir das Update nach der Installation, weil dieses Paket maximal einen Tag alt ist.

Wenn man einen klar definierten Zustand Deines Systems hat, ist es auch erheblich einfacher, Dir weiterzuhelfen. In Deinem aktuellen System weiß doch niemand - nichtmal Du - zuverlässig, was da schon alles verpfuscht wurde.

[Rainer_G]

Ja, werde ich morgen nochmal machen.
Auch wenn das update sauber durchgelaufen ist.
Außerdem schrieb ich ja schon, dass eine rohe Version durchläuft.

Bisher war es schwer zu ermitteln, wann dass Problem losgeht.
Ich habe schon versucht mein fhem.cfg komplett auszukommentieren und dann device für device zuzuschalten.
Als dann die Resets begannen, habe ich das letzte device wieder auskommentiert.
Danach waren die Resets trotzdem noch da.

Allerding habe ich die fhem.cfg jeweils immer via SFTP auf den Raspi kopiert.
Ich werde morgen mal dem Hinweis von Beta-User folgen und die fhem.cfg mit ZOC und nano  bearbeiten.
Vielleicht macht das ein Unterschied.

[Rainer_G]

Übrigens, weder der Antwort noch der Ändern button funktionieren richtig.
Beide öffnen einen uralten Beitrag von mir mit obigem Thema (im Betreff).
Ich habe es schon mit Chrome und Edge ausprobieret.
Das verhalten ist gleich.

[Wernieman]

Du editierst die Config direkt?

Ich würde Dir bei solchen großen Problemen eher empfehlen:
Leeres aktuelles FHEM starten und dan in FHEM selber step by step die Geräte einpflegen. Geht auch per "RAW-Eingabe" copy&paste.

Dann kontrolliert FHEM auch gleich auf "primitive" eventuelle Fehler. Immer noch besser als die Configarbeit diret in der cfg.