FHEM spinnt plötzlich, keine Config-Änderung oder Host-Änderung

[TheTrumpeter]

Von gestern auf heute spinnt FHEM plötzlich auf meinem RPi3, ich habe seit einigen Tagen keine Konfiguration geändert und auf dem RasPi generell schon länger nix mehr geändert.

Heute Früh dann plötzlich der erste (unbemerkte) Neustart, kurz nach dem Essen wieder und vorher schon wieder keine Reaktion.
Zu Mittag habe ich dann noch versucht FHEM zu stoppen, aber der Status blieb immer auf "FHEM is running".
Habe nach dem Neustart dann mal ein FHEM-"update" gemacht, aber auch nun tritt das Problem wieder auf. Diesmal ließ sich FHEM zumindest beim 2. Versuch über den init.d-Befehl beenden und neu starten.

FHEM-Log sieht unauffällig aus, einzig seit dem Update bekomme ich haufenweise Warnings vom FRITZBOX-Modul.
Im Syslog konnte ich auch nichts auffälliges erkennen.

Irgendwelche Hinweise wo ich noch suchen könnte?

[CoolTux]

Habe nach dem Neustart dann mal ein FHEM-"update" gemacht, aber auch nun tritt das Problem wieder auf. Diesmal ließ sich FHEM zumindest beim 2. Versuch über den init.d-Befehl beenden und neu starten.

Das klingt nach einem sehr sehr alten System. Was sagen dann die Logs vom System.

/var/log/syslog
oder eventuell
/var/log/messages

[betateilchen]

FHEM-Log sieht unauffällig aus, einzig seit dem Update bekomme ich haufenweise Warnings vom FRITZBOX-Modul.

"haufenweise Warnings" und "FHEM-Log sieht unauffällig aus" passt für mich aber nicht zusammen.

[Gigafix]

Prüfe mal welches Wetter-Modul du einsetzt. Ich hatte ein ähnliches Problem mit dem abgekündigten DarkSky - siehe auch https://forum.fhem.de/index.php?topic=95823.msg1270972#msg1270972

[TheTrumpeter]

FHEM-Log sieht unauffällig aus, einzig seit dem Update bekomme ich haufenweise Warnings vom FRITZBOX-Modul.

"haufenweise Warnings" und "FHEM-Log sieht unauffällig aus" passt für mich aber nicht zusammen.

Ich habe schon ewig bestimmte Warnings von einem HTTPMOD Device, die ich nicht weg bekomme. Die sind aber schon ewig da.
Sonst war da nix bis zum Update, das ich nur wg. dem beschriebenen Problem gemacht habe. Seitdem wie gesagt neue Warnungen vom FRITZBoX-Modul, sonst nix.

[TheTrumpeter]

Prüfe mal welches Wetter-Modul du einsetzt. Ich hatte ein ähnliches Problem mit dem abgekündigten DarkSky - siehe auch https://forum.fhem.de/index.php?topic=95823.msg1270972#msg1270972

Danke, ich habe PROPLANTA, das funktioniert aber noch.

[TheTrumpeter]

Habe nach dem Neustart dann mal ein FHEM-"update" gemacht, aber auch nun tritt das Problem wieder auf. Diesmal ließ sich FHEM zumindest beim 2. Versuch über den init.d-Befehl beenden und neu starten.

Das klingt nach einem sehr sehr alten System. Was sagen dann die Logs vom System.

/var/log/syslog

Habe im relevanten Zeitraum meiner Meinung nach nix auffälliges gefunden, irgendeine Idee wonach ich im Speziellen suchen soll?

[CoolTux]

von was für einen System reden wir denn überhaupt?

Welche Distri in welcher Version?

[Beta-User]

Würde auf eine kaputte SD-Karte tippen. Scheint ein PI zu sein, der so schon "ewig" lief (original OS scheint noch init.d genutzt zu haben).

[TheTrumpeter]

von was für einen System reden wir denn überhaupt?

Welche Distri in welcher Version?

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch

[CoolTux]

von was für einen System reden wir denn überhaupt?

Welche Distri in welcher Version?

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch

Wie Beta-User schon schrieb. Das System ist Uralt. Ich würde neu installieren mit einer neuen SD Karte.

[betateilchen]

Nur weil jemand noch das fhem-Startskript in /etc/init.d liegen hat, muss das System nicht zwangsläufig veraltet sein.

Bei meinem aktuellen raspbian, das seit jessie von Generation zu Generation updates erfahren hat (immer auf die gleiche SD-Karte...) liegt das Skript dort auch noch. Und man kann damit bei einem manuellen Aufruf auch problemlos das über systemd gestartete FHEM beenden. Es ist ja nix anderes als jedes andere bash-Skript auch.

[CoolTux]

Nur weil jemand noch das fhem-Startskript in /etc/init.d liegen hat, muss das System nicht zwangsläufig veraltet sein.

Bei meinem aktuellen raspbian, das seit jessie von Generation zu Generation updates erfahren hat (immer auf die gleiche SD-Karte...) liegt das Skript dort auch noch. Und man kann damit bei einem manuellen Aufruf auch problemlos das über systemd gestartete FHEM beenden. Es ist ja nix anderes als jedes andere bash-Skript auch.

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch

[betateilchen]

Das hatte ich durchaus zur Kenntnis genommen.
Ändert aber nichts an meiner Aussage zum eindimensionalen Denken.

[TheTrumpeter]

Wie Beta-User schon schrieb. Das System ist Uralt. Ich würde neu installieren mit einer neuen SD Karte.

Frage mich warum das "uralte" System hier irgendeine Relevanz hat.
Der RasPi hat genau 1 Aufgabe, nämlich FHEM mit seinen zahlreichen Modulen zu hosten. Das tut er seit über 6 Jahren zuverlässig.
Ich habe Log2RAM laufen sowie zusätzlich eine kleine RAM-Disk, in der die häufig geänderten Dateien liegen. Die FHEM-Logs liegen auf einem separaten USB-Stick, d.h. die SD-Karte sollte nicht allzu viel beschrieben werden.

Aber gut, falls wirklich nur die SD-Karte der Quell des Übels ist, dann tausche ich die einfach aus. Nur wird der Austausch so stattfinden, dass ich einfach das komplette Image vom 01.04.2023 auf die neue SD-Karte spiele und fertig. (1x monatlich wird die komplette SD-Karte gebackupt.)
Werde das bis zum Wochenende beobachten und dann weitersehen. Seit ich den Thread eröffnet habe, gibt's keine Auffälligkeiten.
Sehe nicht, welchen Vorteil ich davon hätte komplett neu zu starten und alles neu einzurichten, nur um die neueste Distri zu haben... zumal es da noch das Phänomen gibt, zu dem ich gleich unten komme...

Würde auf eine kaputte SD-Karte tippen. Scheint ein PI zu sein, der so schon "ewig" lief (original OS scheint noch init.d genutzt zu haben).

Das wäre mir grad zu viel Zufall. Hintergrund:
Habe vor kurzem 2 Model 3A+ angeschafft, weil ich meinen "Reserve 3B" von seinem Dasein als JDownload-Sklave befreien wollte, um ihn wg. der schlechten Verfügbarkeit der Teile wieder als "Reserve" zum FHEM-RasPi zu haben.
Anstatt einfach nur die SD-Karte vom "JDownload-RasPi" (Buster Lite von 2020) umzustecken, habe ich beschlossen die neueste Distri inkl. grafischer Oberfläche zu nehmen, weil es praktisch ist von unterwegs mit dem Mobiltelefon auf ein System mit grafischer Oberfläche zugreifen zu können (für myJDownloader).
Habe daher "Bullseye" in der 64bit Version auf eine nagelneue SD-Karte gespielt und losgelegt, aber ständig Probleme mit massiven Verzögerungen (über SSH) festgestellt, über VNC ging fast gar nix. Als ich 2016 mit dem Zeug angefangen habe, hab' ich auch erstmal mit grafischer Oberfläche begonnen, solche Probleme gab's da nicht.
Jedenfalls habe ich das Zeug dann beobachtet und festgestellt, dass immer bei den Verzögerungen offenbar SD-Zugriffe stattgefunden haben (grüne LED hat fast ständig geleuchtet). Nach mehrmaligem Neuaufspielen des Images hab' ich dann eine andere ebenfalls nagelneue SD-Karte probiert, da war's genauso.
Hab' dann wieder auf die 1. neue SD-Karte gewechselt und das Image nochmal neu aufgespielt, ein paar Stunden später war die SD-Karte dann hinüber. Bis dahin habe ich nicht mehr gemacht als den SSH-Port zu ändern, ein Netzlaufwerk zu mouten, VNC zu aktivieren und einfach nur über VNC verbunden zu sein. In der Zeit gab's immer wieder diese "Blockaden", ich hab' mir erstmal nix dabei gedacht und die SD-Karte (NoName, die ich irgendwo mal gratis bekommen habe) weggeworfen.
Die 2. SD-Karte (Transcend Premium), von der ein baugleiches Exemplar seit ca. 2 Jahren problemlos in dem "JDownloader-Raspi" läuft, hat wenige Stunden später das Zeitliche gesegnet. Die wird in einem Windows-Rechner zwar noch erkannt, aber als "schreibgeschützt" und die Boot-Partition hat nur fehlerhafte Sektoren, die 2. Partition hat am Anfang noch ein paar gute Blöcke, danach scheint auch alles fehlerhaft zu sein. Die Karte habe ich zuvor noch in dem 2. neuen 3A+ probiert, weil ich einen HW-Defekt am RasPi für das komische Verhalten vermutet habe.
Gestern habe ich dann eine 3. neue Karte (SanDisk Ultra) mit dem letzten "Buster Lite 32bit" Release bespielt, aber noch nicht weiter ausprobiert.
Einerseits kann ich mir nicht erklären was das Verhalten ausgelöst hat, aber andererseits kann ich auch nicht glauben, dass ein offizielles Release von der offiziellen RasPi-Seite so einen massiven Bug hätte, der dieses Verhalten erklären würde.

Und wenn dann jetzt jemand kommt und mir erklären will, dass die SD-Karte vom dem unauffälligen "FHEM-RasPi" praktisch zeitgleich kaputt wird, dann verstehe ich die Welt nicht mehr.