Alle 90 Sekunden Server shutdown und Server startet [gelöst]

Marlon · 23 September 2020, 18:05:12

Heute habe ich im LOG festgestellt, dass mein FHEM-Server auf Raspberry 4B seit 5 Tagen alle 90 Sekunden einen Server shutdown und einen Neustart ausführt.
Alle 90 Sekunden wird dann folgendes ins LOG geschrieben:

Zitat2020.09.23 16:30:45 0: Server started with 19 defined entities (fhem.pl:22726/2020-09-03 perl:5.028001 os:linux user:fhem pid:28134)
2020.09.23 16:32:15 0: Server shutdown
2020.09.23 16:32:15 1: Including fhem.cfg
2020.09.23 16:32:15 3: WEB: port 8083 opened
2020.09.23 16:32:16 2: eventTypes: loaded 37 events from ./log/eventTypes.txt
2020.09.23 16:32:16 3: Opening myCUL device /dev/ttyACM0
2020.09.23 16:32:16 3: Setting myCUL serial parameters to 9600,8,N,1
2020.09.23 16:32:16 3: myCUL: Possible commands: ABbCeFGhiKkLlMmNRTtUuVWXxYZ
2020.09.23 16:32:16 3: myCUL device opened
2020.09.23 16:32:16 2: Switched myCUL rfmode to WMBus_T
2020.09.23 16:32:16 3: WMBUS_SEN_21133475_104_7: I/O device is myCUL
2020.09.23 16:32:16 1: Including ./log/fhem.save
2020.09.23 16:32:16 0: Featurelevel: 6
2020.09.23 16:32:16 0: Server started with 19 defined entities (fhem.pl:22726/2020-09-03 perl:5.028001 os:linux user:fhem pid:28136)
2020.09.23 16:33:45 0: Server shutdown

Dies würde ich gerne abstellen und wäre für jeden Tipp dankbar, wie ich dies erreichen kann.
Das Problem tauchte auf, als ich die fhem.cfg-Datei vom PC auf den Raspi kopiert habe.
Angepasst habe ich darin nur die Parameter der seriellen Schnittstelle für den CUL.

Marlon · 23 September 2020, 19:47:53

Die Ursache des Problems habe ich nun selbst gefunden:
Wenn man die fhem.cfg vom PC kopiert gibt es mehrere Unterschiede gegenüber der auf Raspi kreierten Originaldatei.
Auf dem PC wird in der fhem.cfg z.B. "attr global nofork 1" definiert, was beim Raspi entfällt.
Wenn man das löscht, verschwinden die Server shutdowns alle 90 Sekunden.

Wenn man fhem vom PC auf Raspi umzieht, kann man die fhem.cfg also prinzipiell kopieren.
Zusätzlich sind dann aber folgende Änderungen sinnvoll:
1. Entfernen von attr global nofork 1
2. Ausführen des Patches "define initialUsbCheck notify global:INITIALIZED usb create", "attr initialUsbCheck disable 1"
3. Ggf. ändern der seriellen Schnittstelle des CUL (z.B. zu "define myCUL CUL /dev/ttyACM0@9600 0000")

Aufgefallen ist mir noch, dass ohne "attr global nofork 1" auch die nervigen "connection lost, trying a reconnect every 5 seconds" Meldungen entfallen.

Wernieman · 26 September 2020, 15:37:01

Code Auswählen

define initialUsbCheck notify global:INITIALIZED usb create", "attr initialUsbCheck disable 1"
Dabei wird bei jedem Start von FHEM das initialUsbCheck disabled. Darf eigentlich nicht nötig sein. Also einmal setzen und speichern. Wenn das nicht funktioniert, nach Fehlerursache suchen.

Es gibt übrigens noch ein "Problem" zwischen Windows/Pi. Windos-Editoren setzen (meistens) andere Zeichenenden als Unix. Also besser ... nicht so machen!

guhu · 26 September 2020, 16:01:26

.. Du meinst sicher Zeilenenden. Das ist aber nicht so schlimm, bspw. wird beim Übertragen mit ftp im ASCII-Modus das automatisch gewandelt. Alternativ ein Programm wie dos2unix nutzen.

Marlon · 26 September 2020, 18:35:47

Die unterschiedlichen Zeilenenden sind ja eher eine Sache der Betriebssysteme als von fhem.
Es ist dennoch richtig sie vollständigkeitshalber an dieser Stelle zu erwähnen.
Das fhem-Verzeichnis des Raspi habe ich mit Samba bereitgestellt, so dass ich es unter Windows als normales Netzlaufwerk sehe.
Dann habe ich die fhem.cfg von Windows mit notepad++ geöffnet, im Bearbeiten-Menü die Zeilenenden auf Unix (LF) umgestellt und im fhem-Verzeichnis des Raspi gespeichert.
Ebenso bin ich mit der Zähler-log-Datei verfahren.
Schließlich habe ich noch den Owner der Dateien mit chown fhem:dialout <Dateiname> und deren Rechte mit chmod 777 <Dateiname> geändert.

MadMax-FHEM · 26 September 2020, 18:43:18

Bei dem hier:

Zitat von: Marlon am 26 September 2020, 18:35:47
... und deren Rechte mit chmod 777 <Dateiname> geändert.

Hättest du dir das hier:

Zitat von: Marlon am 26 September 2020, 18:35:47
Schließlich habe ich noch den Owner der Dateien mit chown pi:dialout <Dateiname> ...

sparen können...

...noch dazu wo es FALSCH ist!

Weil, wenn dann:

Code Auswählen


chown fhem:dialout ...

Daher brauchst du dann wohl das 777 doch wieder

Gruß, Joachim

Marlon · 26 September 2020, 19:18:28

Natürlich muss man mit chown fhem:dialout <Dateiname> den Owner zu fhem ändern, damit fhem damit arbeiten kann.

Das hatte ich auch gemacht, nur versehentlich falsch beschrieben und nun oben korrigiert.
Das Problem, das dann entsteht ist, wenn man mit Samba den fhem Ordner freigibt und in Windows als user pi darauf zugreift, man die Dateien unter Windows nicht mehr editieren kann.
Deshalb habe ich dann zusätzlich noch mit chmod 777 <Dateiname> die Rechte so geändert, dass auch user pi darauf freien Zugriff hat.
Für die Funktion von fhem ist dies nicht unbedingt erforderlich aber es vereinheitlicht und vereinfacht einiges.

Wzut · 26 September 2020, 19:21:47

Zitat von: Marlon am 26 September 2020, 19:18:28
vereinfacht einiges.

Klar, vermutlich vor allem das editieren der fhem.cfg ....

Wernieman · 27 September 2020, 17:13:10

... Und die Sicherheit ....

uli2 · 02 März 2022, 16:14:17

Zitat von: Marlon am 23 September 2020, 19:47:53
Die Ursache des Problems habe ich nun selbst gefunden:
Wenn man die fhem.cfg vom PC kopiert gibt es mehrere Unterschiede gegenüber der auf Raspi kreierten Originaldatei.
Auf dem PC wird in der fhem.cfg z.B. "attr global nofork 1" definiert, was beim Raspi entfällt.
Wenn man das löscht, verschwinden die Server shutdowns alle 90 Sekunden.

Wenn man fhem vom PC auf Raspi umzieht, kann man die fhem.cfg also prinzipiell kopieren.
Zusätzlich sind dann aber folgende Änderungen sinnvoll:
1. Entfernen von attr global nofork 1
2. Ausführen des Patches "define initialUsbCheck notify global:INITIALIZED usb create", "attr initialUsbCheck disable 1"
3. Ggf. ändern der seriellen Schnittstelle des CUL (z.B. zu "define myCUL CUL /dev/ttyACM0@9600 0000")

Aufgefallen ist mir noch, dass ohne "attr global nofork 1" auch die nervigen "connection lost, trying a reconnect every 5 seconds" Meldungen entfallen.

2 Jahre später: das gleiche Problem, nach einem update meines Raspi von Jessie auf Bullseye hatte ich ebenfalls ständige unerklärbare Reboots (wohl beim genaueren nachsehen auch alle 90s), hab aber natürlich zuerst and hundert anderen Stellen Fehler vermutet und nach und nach zig Devices entfernt, bis ich nach zwei Tagen auf diesen Thread gestossen bin und tatsächlich, das nofork = 1 war der Übeltäter. Allerdings hatte ich keine Windowsversion umgezogen, und seltsamerweise war das nofork = 1 bei mir auf dem alten Raspi System (mit Jessie) auch gesetzt und hat da offenbar keine Probleme bereitet. Warum das nofork überhaupt gesetzt war kann ich leider nicht mehr nachvollziehen. Aber vielleicht wäre es eine Überlegung wert das Flag ganz zu entfernen, weiss nicht ob das überhaupt noch zu irgendetwas gebraucht wird.
Auf jeden Fall kann es schnell ein paar Tage Fehlersuche kosten und einen zum Verzweifeln bringen