Pi hängt sich in unregelmäßigen Abständen komplett auf

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Ja, es ist bestimmt irgendeine elektromagnetische Einstreuung auf die vielen angeschlossenen Sensorkabel. Aber welche?

    Das mit dem Kernel-Parameter klingt interessant, das kannte ich noch nicht. Muss ich mich mal einlesen.... Danke!

  • Pi hängt sich in unregelmäßigen Abständen komplett auf? Schau mal ob du hier fündig wirst!

  • Hallo zusammen. Ich hole das Thema noch einmal nach oben, da ich über den gesamten Sommer nichts gemacht habe, das Problem jedoch immer noch besteht.

    Ausgangslage ist noch wie im ersten Post beschrieben, mein Pi steuert meine komplette Heizung inkl. Solaranlage und der Pi hängt sich in unregelmäßigen Abständen komplett auf und lässt sich weder per Ping noch SSH erreichen. Problem kann ich also nur durch aus- und anschalten beheben.

    Was mir aufgefallen ist: über den Sommer hatte ich nur zwei der sechs Scripte laufen, im Prinzip hat er nur die Solaranlage und eine Pumpe angesteuert. Die Scripte für Ofen, Fußbodenheizung, 3-Wege-Mischer und Pumpe für Fußbodenheizung hatte ich über den Sommer deaktiviert.

    Der Pi hat sich über den gesamten Sommer vielleicht 2-3x aufgehängt, seit etwa zwei Wochen laufen wieder alle Scripte und ich musste ihn schon 3x komplett ausschalten. Es scheint also so als komme es ab und an mal zu irgendeinem Konflikt während er diese Scripte ausführt.

    Hat irgendjemand eine Idee was ich machen kann um rauszufinden wo das Problem liegt? Über diesen Winter will ich das unbedingt gelöst bekommen.

    Danke!

    EDIT:

    zum Thema elektromagnetische Einstreuung: es waren auch über den gesamten Sommer alle Sensoren angeschlossen, ausgelesen wurden aber nur ein paar.

  • Wenn in den Logfiles kein Hinweis auf den Fehler abgelesen werden kann, würde ich das Netzteil wechseln.

    Verwaiste Prozesse, die den Speicher langsamm füllen (bis er überläuft), sollten auch mit < ps aux > erkennbar sein. Dann hättest Du aber in mehreren Scripts (Sommer und Winter) Schleifenfehler eingebaut.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Hallo,

    ich hatte auch diese Probleme, dass der Raspi sich des Öfteren aufhängte. Dann habe ich ein neues Netzteil gekauft. Hier: Rydges SpeedPower, Rydges Media Technology Braunschweig. Seit diesem Austausch läuft er stabil.

    Viele Grüße

  • Ich habe noch nicht wirklich nachgeforscht was genau passiert. Ich sehe mir heute Abend mal die Logfiles an und sehe ob ich etwas rausfinden kann.

    Was ist das Ergebnis von Beitrag #6? Was passiert bevor der RPi sich verabschiedet? Wie sehen die Skripte aus und wie ist die Auslastung wenn alle laufen?

    Zur vollen Stunden laufen alle Scripte, aber auch da ist die Auslastung kaum messbar. Das längste dauert etwa 20 Sekunden, alle anderen sind in ein paar Sekunden durch. Zwischendurch laufen Scripte im 3, 10 und 30 Minuten Takt. arpings habe ich immer noch nicht versucht.

    Wenn in den Logfiles kein Hinweis auf den Fehler abgelesen werden kann, würde ich das Netzteil wechseln.

    Verwaiste Prozesse, die den Speicher langsamm füllen (bis er überläuft), sollten auch mit < ps aux > erkennbar sein. Dann hättest Du aber in mehreren Scripts (Sommer und Winter) Schleifenfehler eingebaut.


    Servus !

    Schleifenfehler kann ich eigentlich ausschließen, alle Scripte werden ordentlich durchgeführt und auch beendet. Für den Fall das irgendwo ein Fehler passiert (Sensor nicht lesbar o.Ä.) wird das Script beendet.

    Hallo,

    ich hatte auch diese Probleme, dass der Raspi sich des Öfteren aufhängte. Dann habe ich ein neues Netzteil gekauft. Hier: Rydges SpeedPower, Rydges Media Technology Braunschweig. Seit diesem Austausch läuft er stabil.

    Viele Grüße

    Netzteile habe ich schon drei durch, glaube das kann ich mittlerweile ausschließen. Auch Verkabelungsfehler kann ich ausschließen.

    EDIT: falls hier jemand irgendwelche Files braucht um mir helfen zu können bitte melden, dann kann ich euch die gerne zur Verfügung stellen.

  • Bei mir besteht das Problem auch weiterhin. Ich habe es aber einmal in einer Session verfolgen können, bei der ich noch eingeloggt war. Dort bekommt man dann ein I/O-Error auf dem Hauptverzeichnis. Das hat zur folge, dass keine neuen Prozesse mehr gestartet werden können und sich der Rechner aufhängt. Es hat also definitiv mit der Speicherkarte zu tun. Diese produziert wohl einen Fehler, der natuerlich auch durch eine instabile Stronversorgung getriggert werden kann. Kann aber auch von der Karte selbst her kommen. Jedenfalls ist der Effekt dann so, wie hier (oben) beschrieben. Abhilfe muesste dann eine qualitativ bessere Speicherkarte bringen oder ein Stabileres Netzteil, oder eine tolerantere Speicherkarte. Möglicherweise ist es auch EM-Einkopplung über lange Sensorleitungen.

    Was aber nachwievor komisch ist, dass der Watchdog das System nicht wieder hin bekommt.

  • Das ist seltsam, aber ich habe mittlerweile zwei Mal das Netzteil und zwei Mal die Speicherkarte getauscht, daran liegt also wohl eher nicht.

    Aktuell habe ich das "original" Raspberry Netzteil und eine SanDisk Extreme 32GB Speicherkarte verbaut.

  • Jedenfalls ist das bei mir (mindestens) ein weiteres Symptom. Es kann ja auch am Filesystem-Kerneltreiber liegen oder sonstwas/Hardware. Jedenfalls kann man alles was mit Memory-leaks zusammenhaengt dabei ausschliessen.

    Immerhin scheint die SD-Karte nach den naechsten Neustart jedesmal wieder OK zu sein. Es kann also kein dauerhafter Fehler sein.

    Und weiterhin gibt es keine Kernel-Panik. Das System selbst laeuft dann noch. Nur die SD-Karte ist nicht mehr ansprechbar.

  • Und weiterhin gibt es keine Kernel-Panik. Das System selbst laeuft dann noch. Nur die SD-Karte ist nicht mehr ansprechbar.

    Das EXT4 Filesystem löst eigentlich kein Kernel-Panic aus.

    Im EXT4 Error Behavior ist bei den Pi-Distris "continue" oder "remount ro" voreingestellt. Die "panic" Option muss der Admin selbst einstellen, (genauso den Check-Intervall bei 24/7/365 laufenden Systemen)

    Mit .< dumpe2fs -h /dev/xxxx > oder < tune2fs -l /dev/xxxx > ist der EXT4 Superblock-Header für den Admin einsehbar.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Ja, ich konnte aber sehen, dass in dem Fall des "aufhaengens" sogar jeder leseversuch einen "I/O Error" produzierte.

    Der Filesystemtreiber mit "remount ro" kam also gar nciht erst zum Zug. Der Fehler liegt schon weiter vorher beim Block-Device-treiber. Ich vermute daher, dass es kein EXT4 fehler ist.

    Es ist so wie bei meinem Laptop, wenn man mitten im Betrieb einfach mal die Festplatte rauszieht. Der Rechner laeuft dann noch ein wenig aus dem cache, danach kommt irgendwann üeberall I/O Error und alle Prozesse stürzen ab, und danach geht irgendwann gar nix mehr.

  • Ich habe nun eine Abschliessende Diagnose des Problems: Die SD-Karte hat offenbar einen Fehler. Manchmal triggert man diesen Fehler, vielleicht wenn man einen Sektor lesen will, der deinen IO-Error produziert.

    Dann deaktiviert sich die SD-Karte und der Raspberry-Pi muss nun ohne ein root-Dateisystem laufen, was nach kürzerer Zeit dazu führt, dass alle Prozesse haengen oder abstürzen. Neue können wegen des IO-Errors auch nicht gestartet werden. Der Raspi ist also dann ein Zombi.

    Wunderlicherweise kann der Watchdg daran nix aendern. Vielleicht weil die SD-Karte auch nach einem Reset noch nicht wieder aktiviert ist. Erst ein komplettes Stromlos-Machen führt nach dem Wiedereinschalten zu einem dann weiterhin normalen Betrieb.

    Jetzt bin ich dabei, den Fehler auf der SD-Karte einzugrenzen. Ich versuche eine unbenutzte Datei auf den Fehlerhaften Sektor/Bereich zu legen.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!