Raspberry Pi 3 Absturz - IPS Schuld?

Hallo zusammen,

ich habe seit einigen Tagen Abstürze meines Raspberries. Auf diesem läuft eine LCN PCK sowie IPS. Er ist bisher 3 mal Nachts abgestürzt, weswegen z.B. die BWM in den Fluren oder die Regler für die Temperatursteuerung nicht mehr funktionieren. Dadurch ist es zunächst überhaupt aufgefallen.

Die Frage wäre nun, ob dies ein Raspberry oder IPS Problem ist. Ich zeichne z.B. die Leistung meiner Energiezähler auf, und sehe das diese irgendwann mit Konstanten Werten in IPS geloggt werden. Normalerweise schwanken diese immer ein wenig im Minuten Abstand.

Bei einem Blick in die IPS Logfiles konnte ich dann feststellen, dass ich zu dem Beginn der Konstanten Daten immer diese Meldung im Logfile stehen habe:


06/01/21 00:57:15 | 00000 | DEBUG   | DiscoveryServer      | Detected network interfaces change...
06/01/21 00:57:15 | 00000 | DEBUG   | DiscoveryServer      | Leaving multicast group for interface: xxx.xxx.xxx.xxx

Im daemon.log vom RPI finde ich zur gleichen Zeit übrigens sowas. Allerdings kann ich damit leider nichts anfangen:(


Jan  6 00:57:10 raspberry dhcpcd[395]: eth0: hardware address x claims x
Jan  6 00:57:10 raspberry dhcpcd[395]: eth0: hardware address x claims x
Jan  6 00:57:10 raspberry dhcpcd[395]: eth0: 10 second defence failed for x
Jan  6 00:57:10 raspberry dhcpcd[395]: eth0: deleting route to x
Jan  6 00:57:10 raspberry avahi-daemon[382]: Withdrawing address record for xon eth0.
Jan  6 00:57:10 raspberry dhcpcd[395]: eth0: deleting default route via x
Jan  6 00:57:10 raspberry avahi-daemon[382]: Leaving mDNS multicast group on interface eth0.IPv4 with address x.
Jan  6 00:57:10 raspberry avahi-daemon[382]: Interface eth0.IPv4 no longer relevant for mDNS.
Jan  6 00:57:10 raspberry dhcpcd[395]: eth0: probing address x/24
Jan  6 00:57:10 raspberry dhcpcd[395]: eth0: hardware address x claims x
Jan  6 00:57:10 raspberry dhcpcd[395]: eth0: DAD detected x

Wann wird diese Meldung von IPS generiert und falls es ein RPI Problem ist, wo könnte ich weiter suchen?

Magst du kurz noch mal definieren was genau Abstürzt? Ist es IP-Symcon? Oder der ganze Pi? (Geht noch SSH darauf?)#

paresy

Hi,

aber klar, sorry.

Im WF erscheint die Meldung „nicht erreichbar“ und per SSH ist KEIN Zugriff auf den Pi möglich. Eingeschaltet ist er aber noch, zumindest leuchtet die rote LED permanent und die grüne in gewissen abständen.

Läuft auf dem Raspi auch Deine Landroid-Bridge? Wenn ja, dann deaktiviere diese mal bitte. Ist das Problem dann weg?

Jürgen

Hallo,

ja auch dem Server läuft auch die Bridge.
Hatte diese vermeintlich schon vor einigen Tagen deaktiviert, aber dort die alten Befehle vor Stretch genutzt mit:

sudo update-rc.d xxx defaults

Nachher aber nochmal genauer gelesen und gesehen, dass das ab Raspbian Jessie ja lauten muss:

sudo systemctl enable xxx

Das habe ich wie gesagt erst heute morgen gemacht, nachdem der manuelle Neustart aufgetaucht ist. Im Forum zur landroid-bridge, hattest du ja auch schon geschrieben dass es sinnvoller wäre diese über den Winter zu deaktivieren.

Falls es das schon war, wäre das natürlich super.:slight_smile:

deaktivieren bitte mit

sudo systemctl stop xxx
sudo systemctl disable xxx

Jürgen

Wenn SSH nicht mal mehr geht, dann ist IPS eher nicht schuld :slight_smile:

paresy

paresy, darauf würde ich nicht wetten ;).

Ich habe früher öfter das Gefühl gehabt, dass die häufigen ssh Versuche vom GPIO Modul zu Problemen führen, speziell dann, wenn die PIzeroW nicht mehr funktionieren und die Session nicht zustande kommt.

Heute habe ich die Möglichkeit in der Instanz ausgeschaltet.

ja klar, disable nicht enable wie von mir oben :-).
Ich habs mal gemacht und werde beobachten.
Danke euch

Nachdem ich nun 2 Tage keine Probleme hatte, ist der RPI (oder IPS) wieder Abgestürtzt. Ich kann nicht per SSH darauf zugreifen und auch ein Ping ist nicht möglich. Nur nach einem harten reset durch Spannungsversorgung trennen, kann ich wieder darauf zugreifen und IPS startet ganz normal.

Das hier ist der Status vom landroid-bridge Dienst nach dem Neustart:

pi@raspberry:~ $ service landroid-bridge status
● landroid-bridge.service - Landroid Bridge
   Loaded: loaded (/lib/systemd/system/landroid-bridge.service; disabled; vendor
   Active: inactive (dead)
     Docs: https://github.com/weweave/landroid-bridge

Zum Zeitpunkt des Absturzes konnte ich im IPS Logfile wieder diese Einträge finden:

10/01/21 21:15:11 | 00000 | DEBUG   | DiscoveryServer      | Detected network interfaces change...
10/01/21 21:15:11 | 00000 | DEBUG   | DiscoveryServer      | Leaving multicast group for interface: 192.168.xxx.xxx

Sowie danach ständig wiederholend diesen, allerdings bis zum LogRotate um 00:00. Heißt also der RPI arbeitet noch irgendwie oder?


10/01/21 21:32:00 | 19769 | WARNING | ScriptEngine         | Result for Event 19769
<br />
<b>Warning</b>:  Socket is not connected in <b>/-</b> on line <b>2</b><br />
<br />
<b>Warning</b>:  Socket is not connected in <b>/-</b> on line <b>3</b><br />
<br />
<b>Warning</b>:  Socket is not connected in <b>/-</b> on line <b>4</b><br />

10/01/21 21:32:15 | 44956 | MESSAGE | Client Socket        | Applied settings
10/01/21 21:32:15 | 44956 | MESSAGE | Client Socket        | Opening socket...
10/01/21 21:32:15 | 44956 | ERROR   | Event Control        | Reconnecting [Client Socket (LCN Gateway #44012)] failed = Host not found (authoritative)
10/01/21 21:32:15 | 11412 | DEBUG   | Event Control        | Reconnecting [Connect] skipped. Next: 10/01/21 21:35:15
10/01/21 21:33:15 | 44956 | DEBUG   | Event Control        | Reconnecting [Client Socket (LCN Gateway #44012)] skipped. Next: 10/01/21 21:34:15
10/01/21 21:33:15 | 11412 | DEBUG   | Event Control        | Reconnecting [Connect] skipped. Next: 10/01/21 21:35:15

Merkwürdig finde ich auch, dass zwischen den ganzen Meldungen zum „Reconnecting LCN Gateway“ ab und zu Einträge vom Location Modul auftauchen. Das heißt doch das IPS auch noch arbeitet oder?


10/01/21 23:46:22 | 15363 | MESSAGE | VariableManager      | [Location\Altitude - Sonnenhöhe] = -54.0048044285
10/01/21 23:46:22 | 51217 | MESSAGE | VariableManager      | [Location\Azimuth - Sonnenrichtung] = 337.3405927203

Ok, damit ist die Landriod-Bridge als Verursacher ausgeschlossen. Danke für den Versuch und die Rückmeldung. Ich würde Dir dennoch empfehlen, die Bridge in der Winterpause ausgeschaltet zu lassen. Die hat eh gerade keinen Job.

PS: Eine überarbeitete/verbesserte Version der Bridge ist gerade in Vorbereitung.

Jürgen

Deine Debug Logs wirken ja, als wenn es einen IP-Adressen-Wechsel geben würde. Kann das sein?

Kannst du sonst ggf. doch mal Monitor und Tastatur anklemmen und schauen, ob der Pi überhaupt noch lebt. Vielleicht stirbt er ja mit einem Kernel Panic oder ähnlichem.

IP-Symcon sollte niemals in der Lage sein den Kernel/Pi vollkommen zu blockieren. Dafür gibt es normalerweise ne Menge Sicherheitsmachanismen.

Hast du ggf. mal die SD Karte geprüft? Evtl. hat die eine Macke?

paresy

Naja ein und derselbe Pi läuft eigentlich seit >2 Jahren im Netz mit derselben IP. Ich sehe auch nicht das sich dort was in der Fritzbox ändert. Und wenn er nur eine Neu zugewiesene IP bekommt, sollte IPS doch wenigstens im WF erreichbar sein oder?

SD-Karte schließe ich eigentlich aus, da ich im Herbst noch von 32GB auf eine 64 GB gewechselt habe.
Anschließen von Monitor und Tastatur könnte ich nochmal machen ja, ist aber leider aufwendig…

Gibt es denn innerhalb vom Pi keine Möglichkeit sich irgendwelche LogFiles anzusehen, also direkt die vom Pi ohne IPS. Ich bin da leider nicht so firm drin, dass ich wüste wo man sowas sieht. Ansonsten müsste ich nochmal in einem RPI Forum Fragen…

Wenn der Pi gar nicht mehr erreichbar ist, dann ist das mit dem Logs so eine Sache. Du würdest ja gerne mal „dmesg“ aufrufen wollen, um zu schauen, ob es dort relevante Meldungen gibt. Diese Logs sind nach dem Neustart aber immer wieder weg. Deswegen die Idee mit dem Monitor.

paresy

Ach sowas blödes. Naja dann muss ich das mal Aufbauen wenn er wieder hängt. Dummerweise kann ich den nicht einfach an den Schreibtisch neben die Monitore stellen, denn dann würde das LCN Gateway fehlen…

Aber das er nach dem Absturz noch Sachen ins IPS logfile schreibt ist doch merkwürdig oder? Ich meine das zeigt ja schon das er „irgendwas“ macht.

Wie gesagt: Wenn IP-Symcon weiterläuft, dann bedeutet es, dass irgendwas an System-interna abgestürzt ist, was die Fehlerquellen eher richtig SD-Karte, OS, Hardware/Temperatur schiebt.

paresy

Du würdest ja gerne mal „dmesg“ aufrufen wollen, um zu schauen, ob es dort relevante Meldungen gibt. Diese Logs sind nach dem Neustart aber immer wieder weg.

Wenn er die Ausgabe von dmesg in eine Datei schreibt, sollten die Meldungen den Neustart überleben.

dmesg -w >> dmesg.log

wie rufst Du Deinen Pi im Netz auf? Über den Namen oder über die IP-Adresse? Wer vergibt bei Dir den Namen? Macht das die Fritzbox? Als erstes würde mich interessieren, ob Du -wenn der Pi nicht mehr erreichbar ist- ihn noch auf seiner IP anpingen kannst. Wenn das funktioniert, folgt die Frage, ob Du dann auch über die IP (192.168.x.x:3777/) das Web-Front erreichst.

Jürgen

Also zunächstmal lief der Pi jetzt wieder knapp 36h ohne Probleme.

wie rufst Du Deinen Pi im Netz auf? Über den Namen oder über die IP-Adresse? Wer vergibt bei Dir den Namen? Macht das die Fritzbox? Als erstes würde mich interessieren, ob Du -wenn der Pi nicht mehr erreichbar ist- ihn noch auf seiner IP anpingen kannst. Wenn das funktioniert, folgt die Frage, ob Du dann auch über die IP (192.168.x.x:3777/) das Web-Front erreichst.

Ja, die IP ist von der Fritzbox vergeben worden und ich habe sie dort oder im Pi selber nie händisch geändert. Aufrufen tue ich über verschiedene Wege…

  • Für Admin-/Datentransfersachen vom Desktop aus per SSH mit Putty oder WinSCP.
  • Am Smartphone/Tablet per IPS App
  • und an verschiedenen PCs das IPS WF über die IP im Browser.

Nein, wenn mein Problem auftaucht, kann ich die IP nicht anpingen und auch nicht das Web-Front aufrufen.

Code:
dmesg -w >> dmesg.log

Das funktioniert allerdings nur wenn ich es per SSH in ausführe. Das müsste ja irgendwie dauerhaft in ein Logfile geschrieben werden, während des Betriebes.

Ich habe nochmal in die vorhandenen LogFiles(hier aus dem syslog) geschaut. Dieser Block taucht immer zu dem Zeitpunkt auf, wenn IPS abstürzt. Zumindest vermute ich das, denn da setzt das Datenlogging der Energiezähler aus und ist ab dann konstant auf einem Wert

Jan 10 21:14:17 raspberry dhcpcd[438]: eth0: hardware address 50:58:96:76:85:6e claims 192.168.1.10
Jan 10 21:14:18 raspberry dhcpcd[438]: eth0: hardware address 50:58:96:76:85:6e claims 192.168.1.10
Jan 10 21:14:18 raspberry dhcpcd[438]: eth0: 10 second defence failed for 192.168.1.10
Jan 10 21:14:18 raspberry dhcpcd[438]: eth0: deleting route to 192.168.1./24
Jan 10 21:14:18 raspberry dhcpcd[438]: eth0: deleting default route via 192.168.1.1
Jan 10 21:14:18 raspberry avahi-daemon[410]: Withdrawing address record for 192.168.1.10 on eth0.
Jan 10 21:14:18 raspberry avahi-daemon[410]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.10.
Jan 10 21:14:18 raspberry avahi-daemon[410]: Interface eth0.IPv4 no longer relevant for mDNS.
Jan 10 21:14:18 raspberry dhcpcd[438]: eth0: probing address 192.168.1.10/24
Jan 10 21:14:18 raspberry dhcpcd[438]: eth0: hardware address 50:58:96:76:85:6e claims 192.168.1.10
Jan 10 21:14:18 raspberry dhcpcd[438]: eth0: DAD detected 192.168.1.10
Jan 10 21:14:53 raspberry dhcpcd[438]: eth0: Router Advertisement from fe80::e228:6dff:fe95:b5fd

Vor und auch nach diesem Block steht immer dasselbe im SysLog:

Jan 10 20:53:19 raspberry dhcpcd[438]: eth0: Router Advertisement from fe80::xxxx::yyyy::e228::b5fd
Jan 10 20:59:52 raspberry dhcpcd[438]: eth0: Router Advertisement from fe80::xxxx::yyyy::e228::b5fd
Jan 10 21:08:57 raspberry dhcpcd[438]: eth0: Router Advertisement from fe80::xxxx::yyyy::e228::b5fd

Aber nach dieser Uhrzeit sind eben IPS und der Pi nicht mehr erreichbar

Die obere Fehlermeldung sagt, dass die angegebene Macadresse bereits die von dir gewünschte IP benutzt. Daher zieht der Raspberry seinen Wunsch nach dieser IP (bzw. eigentlich den durch die FritzBox vergebenen Zwang zu dieser IP) zurück und schaltet sein Netzwerkinterface aus. Also herausfinden was ist das angegebene Gerät und dessen Konfiguration prüfen.