[Gelöst] FHEM stehengeblieben und nicht mehr erreichbar, wer kann helfen?

[Guzzi-Charlie]

Hallo zusammen,

letzte Nacht ist mein FHEM ohne ersichtlichen Grund stehengeblieben und ist seitdem nicht mehr erreichbar (per Ping war der RasPi noch erreichbar). Dabei hat FHEM/der RasPi auch mein komplettes Netzwerk lahmgelegt. Auch mein NAS-Laufwerk war danach komplett tot.

Ich habe dann die folgenden Maßnahmen versucht:

   
• RasPi  heruntergefahren und neu gebootet
  ==> keine Veränderung, d.h. FHEM Web nicht erreichbar
  ==> NAS nicht erreichbar
  ==> Netzwerk sehr langsam
• RasPi abgeschaltet, das NAS abgeschaltet und neu gestartet
  ==> Netzwerk lief wieder normal
  ==> NAS wieder erreichbar (sowohl das Web-IF als auch alle Datenfreigaben)
• RasPi wieder angeschlossen (incl. Netzwerk) und neu gestartet
  ==> Netzwerk wieder sehr langsam und NAS-LW hat sich ebenfalls wieder aufgehängt und ließ sich erst nach Spannung ausschalten wieder starten und erreichen

Seit der RasPi (4+) aus und vom Netzwerk getrennt ist funktioniert Alles im Netzwerk wieder normal (auch das NAS).
In FHEM ist ein Pfad vom NAS gemountet. Dort werden alle Log-Dateien gespeichert.

Mein Riesenproblem ist nun, daß meine gesamte Hausautomatisierung jetzt tot ist (Glücklicherweise ist die Heizung schon aus).
Ich habe im Moment keinen Plan wo ich anfangen soll zu suchen.

Ich hoffe Jemand da draußen kann mir unter die Arme greifen und Tips geben um das System wieder zum Laufen zu bringen. Ich kann mir das Problem nicht erklären, da am System nichts verändert wurde. Schlimmstenfalls müßte ich das System neu aufsetzen und mein FHEM-Backup wieder einspielen. Ich möchte aber gerne den Grund für das Versagen des Systems herausfinden.

[rudolfkoenig]

Version 1: RasPi vom Netzwerk trennen, Bildschirm und Tastatur anschliessen, RasPi starten, und die FHEM-Logs anschauen
Version 2: die Festplatte der RasPi an das Desktop anschliessen, und FHEM-Logs anschauen. Variante: die Festplatte an einem zweiten RasPi anschliessen, usw.

Uebrigens so ein Betreff kann kontraproduktiv sein, siehe https://tty1.net/smart-questions_de.html#urgent

[Guzzi-Charlie]

Hallo Rudolf,

Danke für den ersten Hinweis. Gerne habe ich auch den Beitrag des von Dir geposteten Links gelesen und stimme fast allen Äußerungen zu. Ich habe deswegen auch meinen Beitragstitel abgeändert.

Den RasPi hatte ich Heute schon aus dem Schaltschrank ausgebaut und direkt mit Tastatur und Monitor versehen und dann (am Schreibtisch) neu gestartet, konnte da aber leider auch keinen Hinweis auf das Problem herauslesen. Die kompletten Bootmeldungen kann ich aber natürlich nochmal erzeugen und hier posten. Das Fhem.log konnte ich einfach auslesen, da es ja sowieso auf dem NAS liegt. Da brauchte ich den RasPi gar nicht für.

Im fhem.log kann ich auch nichts erkennen. Die einzige Error-Meldung kam ca. ein halbe Stunde bevor fhem stehengeblieben ist:

Code Auswählen Erweitern

2021.05.31 23:35:57.372 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_FHEM_Server_192.168.178.210_58084
Die kommt von meiner E-Auto Wallbox und kommt öfter. Die ist noch nicht vollständig implementiert.

Danach gab es nur einige "Warnings":

Code Auswählen Erweitern

2021.05.31 23:57:43.916 1: Das Notify n_test hat ausgeloest.
2021.05.31 23:57:43.916 1: Das Device MQTT2_D1Mini_E39DC5 hat ausgeloest, der Event sah so aus: Temperatur_011912630EA1: 23.3
2021.05.31 23:58:13.727 1: Das Notify n_test hat ausgeloest.
2021.05.31 23:58:13.727 1: Das Device MQTT2_D1Mini_5F7437 hat ausgeloest, der Event sah so aus: Temperatur_0119128F72B7: 42.9
2021.05.31 23:58:13.735 1: Das Notify n_test hat ausgeloest.
2021.05.31 23:58:13.735 1: Das Device MQTT2_D1Mini_5F7437 hat ausgeloest, der Event sah so aus: Temperatur_0119128890C4: 43.3
2021.05.31 23:58:27.589 1: PERL WARNING: Possible precedence problem on bitwise | operator at (eval 45694848) line 3.
2021.05.31 23:58:27.590 1: PERL WARNING: Possible precedence problem on bitwise | operator at (eval 45694849) line 3.
2021.05.31 23:59:13.707 1: Das Notify n_test hat ausgeloest.
2021.05.31 23:59:13.707 1: Das Device MQTT2_D1Mini_5F7437 hat ausgeloest, der Event sah so aus: Temperatur_0119128A2C22: 43.1
2021.05.31 23:59:13.715 1: Das Notify n_test hat ausgeloest.
2021.05.31 23:59:13.715 1: Das Device MQTT2_D1Mini_5F7437 hat ausgeloest, der Event sah so aus: Temperatur_01191278D0A5: 43.1
2021.05.31 23:59:28.946 1: PERL WARNING: Possible precedence problem on bitwise | operator at (eval 45696729) line 3.
2021.05.31 23:59:28.948 1: PERL WARNING: Possible precedence problem on bitwise | operator at (eval 45696730) line 3.
==> Das war der letzte Eintrag
Bei den Neustarts in der Nacht gab es nur zwei Einträge:

Code Auswählen Erweitern

2021.06.01 02:00:26 3: [UtilsHourCounter] Init Done with Version 1.0.1.0 - 10.12.2014 (john)
2021.06.01 02:00:26.439 1: Including fhem.cfg

Auch bei den weiteren Versuchen gab es praktisch keine Einträge:

Code Auswählen Erweitern

2021.06.01 09:59:37 3: [UtilsHourCounter] Init Done with Version 1.0.1.0 - 10.12.2014 (john)
2021.06.01 09:59:37.903 1: Including fhem.cfg
2021.06.01 19:50:17 3: [UtilsHourCounter] Init Done with Version 1.0.1.0 - 10.12.2014 (john)
2021.06.01 19:50:17.633 1: Including fhem.cfg
Das kommt wahrscheinlich daher, daß das NAS sich aufhängt und dann sowieso nichts mehr gespeichert werden kann.

[rudolfkoenig]

Die CONNACK Meldung weist auf eine kaputte Verbindung oder auf einen Fehler in meiner MQTT Implementierung hin.
Ich tippe aufs Erste

Die Logs auf die NAS zu schreiben kann zu einem Problem werden, wenn NAS oder Netzwerk kaputt sind (ach was), und das kann zu einem verklemmten FHEM fuehren.

Um zu pruefen, ob RasPi / FHEM die Ursache oder nur Mitleidende sind, wuerde ich FHEM auf dem netzwerklosen RasPi mit "cd /opt/fhem; perl fhem.pl -d fhem.cfg" in der Console starten, und schauen, wie weit es kommt.

Als naechstes wuerde ich alle Geraete und Netzwerk anschliessen, weiterhin mit Bildschirm und "perl fhem.pl -d fhem.cfg".
Falls moeglich, waere eine Verbindung ueber ein alternatives Netzwerk (WLAN statt LAN, etc) interessant, um die Ursache zu lokalisieren.

[Guzzi-Charlie]

Hallo Rudolf,

Die MQTT-Meldung macht mir eigentlich keine Sorgen. Klar, offensichtlich stimmt da auch was nicht, aber die Wallbox ist, wie schon gesagt, noch nicht richtig implementiert.

Wenn NAS oder Netzwerk defekt wären dann kann fhem natürlich nichts schreiben. Das ist auch klar, aber wenn die SD-Karte defekt wird passiert ja genau das Gleiche und ich glaube die Wahrscheinlichkeit das die SD-Karte stirbt ist größer als das das NAS aufgibt. Zumal das NAS auch im Raid1 betrieben wird. Aber was wäre die Alternative?

So, dann bin ich mal gemäß Deinen Tips vorgegangen:

   
• Start des RasPi ohne Netzwerk
  ==> ergibt folgendes (siehe Anhang ...154.jpg). Bis dahin keine Fehlermeldungen.
• Start von fhem über die Konsole
  ==> endet in einer Endlosschleife. Das geht aber so schnell, daß ich die Meldungen nicht prüfen kann.
• Start von fhem über eine alternative Verbindung (WLAN statt LAN)
  ==> beginnt mit dem Hochfahren und Anlegen verschiedener Dateien und endet wieder mit dem "Stehenbleiben" von fhem (siehe Anhang ...406.jpg)
  und dem "Aufhängen" des NAS welches sich wiederum nur per Aus- und Einschalten wieder zum Leben erwecken läßt.

Ich habe die meisten Log's als Monatslogs angelegt. Kann es sein, daß es irgendetwas damit zu tun hat weil Vorgestern in der Nacht, als FHEM stehengeblieben ist, war ja der Übergang zu einem neuen Monat.

[rudolfkoenig]

==> endet in einer Endlosschleife. Das geht aber so schnell, daß ich die Meldungen nicht prüfen kann.

Vielleicht ist aber dein Fotoapparat schnell genug
Manche Konsolen hoeren auf Ctrl-S (Stop output) / Ctrl-Q (Continue with output), womoeglich kannst Du die Ausgabe damit stoppen.

Im letzten Screenshot (...406.jpg) sieht man oben was von "Permission denied" beim oeffnen einer Datei auf dem NAS.
Da die letzte Meldung (define FileLog ...) vermutlich auf dem NAS eine Datei anfassen will und nicht weiterkommt, tippe ich darauf, dass auf dem NAS der FHEM-Ordner kaputt ist. Ich wuerde in den NAS Logs nach Festplattenfehler suchen, je nach Ergebnis das FHEM-Verzeichnis auf dem NAS einpacken und dann wieder auspacken (damit alle Dateien neu geschrieben werden), oder wenn das nicht funktioniert, ein Backup restaurieren.

[Guzzi-Charlie]

Hallo,

ich bin bisher leider mit der Original FHEM-Konfiguration kein Stück weiter gekommen. Trotzdem haben mich die Tips/Ratschläge ein Stück weitergebracht, auch wenn mir der Vorschlag die Netzwerkverbindung statt per LAN mal per WLAN zu testen erstmal neue Probleme gebracht und keine alten gelöst hatte. Beim Einrichten des WLAN's muß ich wohl irgendeinen Konfigurationsfehler gemacht haben (den ich bisher auch noch nicht gefunden habe), denn seitdem funktioniert der LAN-Port nicht mehr. Aber das ist gerade nicht ganz so wichtig. Das werde ich schon wieder hinkriegen.

Auch mit der Verbindung per WLAN gab es keine Verbesserung der Situation. Sobald der RasPi gebootet hatte war mein NAS nicht mehr erreichbar. Das liegt aber mit ziemlicher Sicherheit NICHT am NAS, denn die Dateien lassen sich problemlos lesen. Ich habe dann (erstmal als Sofortmaßnahme) den Pfad für die Log-Dateien auf einen direkt am RasPi angesteckten USB-Stick umgeleitet. Das hat anfangs auch etwas rumgezickt. Erst wollte der RasPi den Stick nicht richtig mounten/einhängen und dann gab es noch etwas Widerstand gegen die Schreibversuche von FHEM, aber das klappt jetzt und die Log-Dateien werden auf dem USB-Stick angelegt und geschrieben.

Als nächstes habe ich die originale fhem.cfg gegen die Demo.cfg ausgetauscht und siehe da FHEM-WEB war wieder erreichbar. Danach habe ich dann eine alte fhem.cfg vom Januar 2021 aktiviert und getestet. Auch damit war dann FHEM-WEB erreichbar und FHEM hat entsprechend der Konfi funktioniert. Morgen werde ich dann schrittweise weitere (Neuere) fhem.cfg's testen und hoffe am Ende mein altes System wieder zum Laufen zu bringen.

Bisher habe ich allerdings leider noch keine direkte Ursache verifizieren können.

Updates schreibe ich sobald es was Neues zu berichten gibt.

[CoolTux]

Code Auswählen Erweitern

Was mich als lesender verwirrt ist Deine Fehlerbeschreibung.
[quote]
Sobald der RasPi gebootet hatte war mein NAS nicht mehr erreichbar.

Ich lese es so das das NAS komplett im Netz nicht mehr erreichbar ist sobald der Raspi gebootet ist. Also kein Ping kein gar nichts egal von welchen Rechner aus.
Ist das so?
Oder kann nur der Raspi kein Ping auf das NAS mehr?
Oder meinst du vielleicht das nur der Storageservice also einbinden des NAS Netzwerkdateisystems nicht mehr klappt?

Wichtige Fragen.

[Papaloewe]

Nur so ein Schuss in Blaue:

Hat der Raspi eventuell dieselbe IP-Adresse, wie dein NAS?

[Wernieman]

Mal eine andere Frage:
Wenn Du FHEM nicht laufen lässt, aber den Pi, läuft dann Dein Netzwerk?

[Guzzi-Charlie]

Hallo Zusammen,

Danke für Eure Hinweise.

@CoolTux:
Ja, das war genau so. Immer wenn der RasPi gebootet hatte und am Netz hing war das NAS blockiert und nicht mehr erreichbar. Selbst mein Windows-Explorer ist dann stehengeblieben weil er nicht mehr auf das NAS zugreifen konnte. Auch nach Ausschalten des RasPi blieb das NAS tot. Erst nach einem harten Aus- und wieder Einschalten war es wieder erreichbar. Ähnliches ist vor einiger Zeit schonmal vorgekommen. Da half dann auch nur Aus- und wieder Einschalten, aber danach lief ALLES (auch mit RasPi) wieder normal. Ich habe immer noch den leisen Verdacht, daß es an der Menge der zum Monatsübergang neu anzulegenden Logdateien liegen könnte da alles genau um 23:59:xx stehengeblieben ist. Da ich die meisten Logs als Monats-Logs angelegt habe müssen diese ja an jedem 1. neu angelegt werden. Das sind immerhin ca. 250 Dateien.

Fakt ist jedenfalls, daß das NAS als Solches einwandfrei funktioniert und RasPi und FHEM jetzt auch wieder, nachdem ich die Log-Dateien nun auf einen USB-Stick schreibe der direkt am RasPi eingesteckt ist.


@Papaloewe:
Nein, natürlich nicht. Beide haben unterschiedliche und feste IP-Adressen. Es wurde ja auch nichts verändert. Das System ist halt im normalen Betrieb einfach "stehengeblieben".


@Wernieman:
Das Netzwerk als solches läuft wenn der Pi gebootet ist (egal ob mit oder ohne FHEM), wenn auch spürbar langsamer. Aber sowie ich FHEM gestartet hatte und es auf das NAS zugreifen wollte war alles vorbei.


Ich glaube ich werden dem Problem jetzt auch nicht mehr tiefer auf den Grund gehen (auch wenn ich praktisch nicht wirklich was gefunden habe). Dafür fehlt mir die Zeit und die Muße.
 
Es gibt jetzt nur noch zwei Dinge zu tun:

   
• herausfinden warum der LAN-Anschluß seit dem Aktivieren des WLAN's nicht mehr funktioniert (auch nachdem ich dem RasPi temporär das WLAN wieder weggenommen hatte).
• herausfinden warum die vpiccu3 auch nicht mehr läuft. Der Winter ist ja Gott sei Dank vorbei und die Heizungsregelung (für mehr ist Homematic bei mir nicht zuständig) wird zur Zeit nicht benötigt.

Vielleicht hat hierzu ja auch Jemand einen Tip wo ich anfangen könnte zu suchen.


Und nochmal Danke für die bisherigen Antworten.

[Guzzi-Charlie]

Update:
Der LAN-Anschluß des RasPi funktioniert auch wieder. Ich hatte bei der von Rudolf für Testzwecke empfohlenen Aktivierung der WLAN-Schnittstelle aus Versehen eine Zeile in der "interfaces"-Datei gelöscht. Seit der Neukonfiguration der Datei funktioniert der LAN-Port jetzt wieder.

Jetzt muß ich nur noch die vpiccu3 wieder zum Laufen bekommen und dann ist Alles wieder Gut.

Also falls sich hier Jemand auch mit der virtuellen CCU3 auf dem RasPi auskennt (ist ja nicht direkt ein FHEM-Problem), dann bin ich für jeden Tip dankbar. Ich kenne mich in den Tiefen von Raspian nicht besonders gut aus und muß mir das teilweise recht mühsam aus den Weiten des Internets zusammensuchen und immer wieder neu testen bis es endlich funktioniert.

[Wernieman]

Also irgendwie hat Dein NAS ein Problem, wenn 250 Neue Dateien es aus den Tritt bringen ...

Wie ist es denn Angebunden? NFS (Version?), CIFS o.Ä?
Und was ist es für ein NAS?

Meine NAS hier, eine kleine Synology, kann ich jedenfalls mit so etwas NICHT aus dem Tritt bringen .. geschweige denn das Netzwerk

[Guzzi-Charlie]

Wie gesagt ist das nur eine Vermutung. Es war halt auffällig das FHEM und das NAS genau am Monatswechsel "stehengeblieben" sind.

Ich hatte die Logs auf das NAS (in Raid 1 Konfi) ausgelagert weil ich damit einem schnelleren Tod der SD-Karte etwas vorbeugen wollte. Jetzt werden die Logs erstmal auf einen USB-Stick geschrieben. Dann mache ich halt öfters ein Backup.

Ich werde dem Problem auch nicht weiter nachgehen, nachdem FHEM jetzt wieder funktioniert. Da habe ich weder Zeit noch die Muße zu.

Daß das NAS selbst ein Problem hat glaube ich eher nicht. Das ist zwar schon etwas älter, aber funktioniert tadellos seit Jahren. Es ist ein D-Link DS320. In FHEM eingehängt war es per CIFS. Ich habe auch schon eine neue Synology Diskstation DS220j hier stehen (weil ich die Performance etwas steigern wollte nachdem ich auch das Netzwerk auf GBit-LAN umgestellt hatte) die eigentlich das alte NAS ersetzen sollte, aber ich komme mit der Rechteverwaltung des Synology absolut nicht zurecht. Ich habe Tage damit zugebracht und versucht das einzurichten, leider ohne Ergebnis. Ich war schon kurz davor den Mist wieder zurückzuschicken. Vielleicht bin ich auch einfach nur zu blöd dazu. Wahrscheinlich werde ich es irgendwann nochmal versuchen. Bis dahin bleibt es beim alten NAS.

[Guzzi-Charlie]

Update:
So, die pivccu3 ist auch wieder erreichbar und funktioniert. Die Ursache war im Prinzip die Gleiche wie bei der LAN-Schnittstelle, also eine fehlende Einstellung  in der "interfaces"-Datei.

Ganz verstehe ich zwar die Einstellungen, bzw. deren Wirkungsweisen nicht, aber nach vielem Suchen, Lesen und experimentieren läuft nun wieder Alles wieder wie vorher.
Meine "interfaces"-Datei im RasPi sieht jetzt folgendermaßen aus:

Code Auswählen Erweitern

auto lo
iface lo inet loopback

auto br0
iface br0 inet dhcp
bridge_ports eth0

auto eth0
iface eth0 inet static
address 192.168.178.130
netmask 255.255.255.0
broadcast 192.168.178.255
network 192.168.178.0
gateway 192.168.178.1

Obwohl ich letztendlich die Ursache für das "Stehenbleiben von FHEM" nicht gefunden habe hat mir die Fehlersuche doch wieder einige neue Erkenntnisse gebracht. Danke nochmal an Alle die versucht haben zu helfen.

[Wernieman]

auto br0

Du hast eine Bridge auf dem Pi am Laufen?

[Guzzi-Charlie]

Ja, das ist  für die 2. Ethernet-Adresse des pivccu3-Containers. Aber ehrlich gesagt weiß ich nicht wirklich genau wie das funktioniert. Das habe ich aus der Anleitung zur Einrichtung der pivccu3 übernommen.

Der RasPi hat ja nur einen Ethernet-Port und den verwendet FHEM (bei mir die IP ...130). Die pivccu3 benötigt eine eigene IP (bei mir die ...129). Das wird dann über die bridge realisiert. Hab ich zumindest so verstanden. Das hat auch eine Weile gedauert bis das funktioniert hat. Ich wollte keinen zweiten RasPi (nur für das bisschen Homematic) haben.

[Wernieman]

Wenn es läuft .... wundert mich nur ...

pivccu3-Containers

Ist doch ein Docker-Container? Weißt Du, welchen Netzwerkmode verwendet wird?

[Guzzi-Charlie]

Ich weiß nur das die pivccu3 ohne die bridge NICHT läuft. Die bridge hatte ich ja bei meinen Bemühungen FHEM nach dem "Stehenbleiben" wieder zum Laufen zu bringen entfernt. Danach war die pivccu3 nicht mehr zu erreichen.

Was den "Container" betrifft so weiß ich ehrlich gesagt überhaupt nicht mehr wie ich das damals genau installiert hatte. Das ist schon 1,5 Jahre her. Ich hatte damals jede Menge gesucht, gelesen und probiert und die pivccu am Ende nach einer Anleitung (ich meine von Github) installiert. Ob das jetzt ein Docker-Container ist oder nicht kann ich gar nicht sagen. Das Wort "Container" hatte ich nur als Synonym verwendet weil die APP parallel zu meiner FHEM-Installation auf dem gleichen RasPi läuft.