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

  • Hallo zusammen,

    so, nachdem ich jetzt einiges gelesen habe und auch schon probiert habe muss ich mich an die Experten wenden.

    Im Einsatz ist ein Pi 2, Model B+, der sich in unregelmäßigen Abständen komplett aufhängt. Wenn das passiert leuchtet die LED noch, alle GPIOs behalten ihren aktuellen Status aber ich kann ihn weder anpingen noch über SSH erreichen. Normalerweise greife ich einfach über RDP zu (wenn nötig).

    Es laufen insgesamt fünf Python Scripte die in verschiedenen Intervallen insgesamt 20 Relais schalten, ein Webinterface auf WebIOPi Basis und 1wire mit 20 Sensoren, ansonsten macht der nichts.

    Angeschlossen ist bis auf LAN auch nichts, auch keine USB Geräte.

    Getestet habe ich bisher:

    • Neues Netzteil (jetzt original)
    • Neue SD-Karte (2x SanDisk bisher)
    • Komplett neuer Pi

    Zum Test lasse ich ihn jede Nacht neu starten, wenn das Problem jedoch tagsüber auftritt und ich es nicht merke startet er auch nicht neu. Ohne Neustart läuft er manchmal 1-2 Wochen ohne Probleme durch, manchmal hängt er sich aber auch an einem Tag 2x auf, wovon das abhängt und durch was das ausgelöst wird ... keine Ahnung :(

    Da der unter anderem auch meine Solaranlage steuert muss ich das Problem unbedingt lösen bevor der Sommer kommt. Wäre sehr dankbar um ein paar Tipps.

    Danke!

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

  • Ja, Verkabelungsfehler sind auszuschließen. Im Grunde genommen machen die Scripte nichts außer Temperaturen messen und Relais schalten. Bei jedem Durchlauf wird jeweils eine txt-Datei erstellt, die wird aber jedes Mal überschrieben. Datenbank liegt da keine dahinter.

  • ... aber ich kann ihn weder anpingen noch über SSH erreichen. ...

    , wenn das Problem jedoch tagsüber auftritt und ich es nicht merke startet er auch nicht neu. ...

    Teste mal (temporär) ob dein PI2 in der Lage ist auch dann zu rebooten, wenn er von außen per Ping oder per ssh nicht mehr erreichbar ist.

    Z. B. mit einem Script und einem cronjob. Im Script lässt Du deinen PI2 arpings (arp-Protokoll) auf den Router/gateway machen. Wenn vom Router/gateway keine Antwort auf den arping kommt, dann wird dein PI2 durch das Scripte rebootet. Das rebooten bzw. die Zeit des reboots, kannts Du mit dem Script auch loggen lassen. Mit dem Script könntest Du auch RAM-/CPU-Auslastung, Anzahl der Verbindungen und andere relevante Kennwerte, aus der Zeit unmittelbar vor dem reboot feststellen und temporär loggen.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Teste mal (temporär) ob dein PI2 in der Lage ist auch dann zu rebooten, wenn er von außen per Ping oder per ssh nicht mehr erreichbar ist.

    Z. B. mit einem Script und einem cronjob. Im Script lässt Du deinen PI2 arpings (arp-Protokoll) auf den Router/gateway machen. Wenn vom Router/gateway keine Antwort auf den arping kommt, dann wird dein PI2 durch das Scripte rebootet. Das rebooten bzw. die Zeit des reboots, kannts Du mit dem Script auch loggen lassen. Mit dem Script könntest Du auch RAM-/CPU-Auslastung, Anzahl der Verbindungen und andere relevante Kennwerte, aus der Zeit unmittelbar vor dem reboot feststellen und temporär loggen.

    Das ist eine geile Idee, wusste nicht dass das geht. Das wäre wirklich interessant zu wissen ob das klappt. Das muss ich unbedingt versuchen, würde mir als Notlösung vorerst schon reichen. Ich merke es einfach zu spät wenn er sich aufgehängt hat, meistens erst wenn irgendein Raum ungewöhnlich warm oder kalt ist, oder meine Frau duschen will und das Wasser nicht warm ist ;)

    Neben scipteigenen Txt-Files erstellt Linux aber auch Logfiles (in /var/log/).

    Da könnte ein Fehlerhinweis enthalten sein.


    Servus !

    Danke, ich werde da gleich mal reinschauen wenn ich zu Hause bin.

  • Ich merke es einfach zu spät wenn er sich aufgehängt hat, meistens erst wenn irgendein Raum ungewöhnlich warm oder kalt ist, oder meine Frau duschen will und das Wasser nicht warm ist

    Oh, da solltest Du aber zwingend für Redundanz sorgen, denn so etwas darf nicht passieren. ;)

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Falls es Dich tröstet, ich habe genau dasgleiche Problem mit meinem Pi B+. Er laesst sich im Aufgehängten Zustand nicht mal mehr per watchdog rebooten. Der haengt also auch. Wenn hier neuere Erkenntnisse auftauchen, waere ich auch interessiert! Ich hab auch schon eine Menge probiert, bin aber noch nicht weitergekommen und das Problem besteht weiterhin (Aufhaengen nach einigen Tagen dauerbetrieb.)

  • im Aufgehängten Zustand nicht mal mehr per watchdog rebooten

    Bitte? Meines Erachtens ist der in Hardware ausgeführt. Es sollte mich schon sehr wundern, wenn das nicht geht. Oder meintest Du etwas anders als die Nutzung von /dev/watchdog ?

    Grüße, STF

  • Genau das meine ich. Und es wundert mich auch sehr. Aber der watchdog funktioniert, wenn man ihn vom watchdog-daemon ausloesen laesst (z.b. wenn er die aktivitaet auf einem File überwachen soll), aber nicht, wenn der Pi sich aufhaengt. Sonst waers mir ja egal, wenn der pi von selbst wieder neustarten taete. Aber das macht er nicht. Man muss die Stromversorgung trennen damit er wieder was tut.

  • watchdog-daemon ausloesen laesst

    Der löst nix aus, sondern schreibt in den geforderten Abständen auf den watchdog (Standard 15 Sek.). Passiert das nicht, wird hart neu gestartet.

  • Wurde schon einmal versucht mit journalctl etwas herauszufinden?

    Um den genauen Zeitpunkt des Stillstandes zu ermitteln bzw. festzuhalten würde ich mir ein kleines Shell-Script bauen, das einfach alle 1-5 Sekunden mit dem touch-Befehl immer wieder die gleiche Datei anlegt. Nach dem Aufhängen des Pi und anschließendem Neustart kannst Du dann mit Blick auf die Datei dann auf wenige Sekunden eingrenzen, wann das Aufhängen genau passiert ist (ls --full-time <Datei>).

  • Ja,dannmuss ich aber das ganze Dateisystem ohne write-cache aufsetzen. Das will ich eigentlich nicht. Ich möchte eher verstehen, was sich aufhaengen kann, so dass der Hardware-watchdog-timer auch nicht mehr geht.

  • Die Systemprotokolldaten lassen sich auch per LAN an einen anderen Rechner senden, die müssen nicht am eigenen Rechner gespeichert werden.

    Ich frage mich aber, ob es soviel bringt, den Störzeitpunkt auf die Millisekunde genau zu ermitteln. Du weisst ja dann auch nicht, ob der "Burst" aus dem Stromnetz, oder on Air kommt.

    Mit einem Netzfilter vor dem Netzteil und/oder kleinen Kapazitäten Induktivitäten in den Datenleitungen müsstest Du dann sowieso der Störung begegnen, wenn Du auf die Ursache keinen Einfluss hast (z.B. Smartmeter, Parkscheinautomat, EVU-Steuerung, Solaranlage des Nachbarn ...)

    So ein panikloses Einfrieren ist auch untypisch für Linux. Da muss ganz tief im System ein Adresspointer oder Soeicherbereich verfälscht werden. Die einfachste Erklärung wäre ein Bug in den neuen Firmware-Treibern. Sowas sollte aber in den To Do Listen der ARM/pi Entwicker ersichtlich sein.


    Servus !

    Edit: Abs.3 auf Induktivitäten berichtigt

    RTFM = Read The Factory Manual, oder so

    Einmal editiert, zuletzt von RTFM (1. Juni 2018 um 21:31)

  • Ich möchte eher verstehen, was sich aufhaengen kann, so dass der Hardware-watchdog-timer auch nicht mehr geht.

    Evtl. einen Kernel kompilieren, mit z. B.:

    Code
    CONFIG_WATCHDOG_NOWAYOUT=y

    Siehe:

    Code
    zcat /proc/config.gz | grep -i WATCHDOG_NOWAYOUT

    EDIT:

    https://www.mjmwired.net/kernel/Documen…hdog-api.txt#50

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (31. Mai 2018 um 10:30)

  • Ich hab mal gerade in diesen Thread reingeschnuppert und mir fiel spontan dies ein:

    https://www.heise.de/newsticker/mel…us-2544288.html

    Oder irgendeine Hardware, die einen elektromagnetischen Impuls einstreut, in der Nähe?

    Funktelefon(e), Relais ohne/kaputte Ableitdiode, Gastherme mit Piezozünder, ...

    Aber warscheinlich liege ich mit meinem Gedankenblitzchen voll daneben.

    MfG

    Jürgen

Jetzt mitmachen!

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