Rasbian Buster stürzt häufig ab - Warum?

  • Die habe ich eingetragen. Nur fürs Forum wieder ersetzt.

    Dann installiere sysstat und logge den CPU- und Speicher-Verbrauch.

    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-p3 (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

    • Offizieller Beitrag

    Ich glaube nicht, dass rngd das Problem ist, denn in und kurz nach dieser Zeit ist mein RPi zumindest erreichbar.

    Btw.

    um online Skat spielen

    Habe ich leider lange nicht gespielt, obwohl ich aus dem ehemaligen Kreis Altenburg / heute Altenburger Land stamme. :blush: SKAT wurde ja, wie Du sicher weißt, in Altenburg erfunden. ;)

  • ..., denn in und kurz nach dieser Zeit ist mein RPi zumindest erreichbar.

    Kann sein, aber ein Problem ist das trotzdem, denn der PI muss immer und sofort erreichbar sein.

    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-p3 (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

    • Offizieller Beitrag

    Kann sein, aber ein Problem ist das trotzdem, denn der PI muss immer und sofort erreichbar sein.

    Genau und um das herauszufinden gilt es eben. Vielleicht wurde in Buster ein (neuer) Screensaver inkl. Stromsparmodus (oder vergleichbar) eingebunden. Ich jedenfalls hatte vor Buster dieses Verhalten nicht feststellen können. Da rief ich in PuTTY einen RPi auf auf und der war sofort "da".

  • Ich jedenfalls hatte vor Buster dieses Verhalten nicht feststellen können. Da rief ich in PuTTY einen RPi auf auf und der war sofort "da".

    Ist das ein PI4 oder ein PI3, mit Buster?

    Mit welchem Betriebssystem benutzt Du PuTTY?

    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-p3 (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

  • - SSH Verbindung (Port 22) funktioniert nicht. Bei Putty kommt aber kein Timeout oder Connection Error. Ist der Raspberry ausgeschaltet, kommt von Putty nach kürzester Zeit ja Connection Error.

    - Telnet zum Raspberry (Port 23) funktioniert nicht.

    - Die rote LED am Raspberry leuchtet dauerhaft.

    - Die grüne LED am Raspberry blinkt recht schnell und durchgängig gleichmäßig.

    Habe dann um etwa 19:35 Uhr das Stromkabel gezogen und anschließend in die Logs geschaut. Richtig weg ist er nicht, er macht noch Dinge und merkt auch, dass ich eine Tastatur angeschlossen habe.

    BTW: Für die Fehlersuche ist nicht entscheidend ob eine funktionierende/brauchbare ssh- oder telnet-Verbindung zu deinem PI hergestellt werden kann, sondern ob der PI auf einfache Portscans (Ports 22 und 23) _aus dem (W)LAN_ antwortet oder nicht antwortet. Z. B.:

    Code
    :~$ nc -zv 192.168.178.40 23
    Connection to 192.168.178.40 23 port [tcp/telnet] succeeded!

    Du hast doch "dtparam=act_led_trigger=heartbeat" auf deinem Pi konfiguriert, oder?

    Wenn ja, weißt Du dann wie die grüne Led am PI zu blinken hat? Das darf kein durchgängig gleichmäßiges Blinken sein. Kannst Du einen Unterschied im Blinken der grünen Led an deinem PI feststellen, sofort nach dem booten, wenn dein PI per ssh oder telnet noch erreichbar ist und zu einem Zeitpunkt wenn dein PI per ssh oder telnet nicht mehr erreichbar ist?

    Stromkabel ziehen ist nicht gut. Schreibe ein Script das auf dem PI (per cronjob oder timer-unit) prüft ob dieser von außen nicht mehr erreichbar ist, und wenn das der Fall ist dann soll sich der PI selber rebooten (so dass Du nicht immer das Stromkabel ziehen muss).

    EDIT:

    Teste mal auf deinem PI mit prlimit, ob für die relevanten/lauschenden Dienste (daemons) auf deinem PI, die CPU-Zeit auf "unlimited" gesetzt ist. Z. B.:

    Code
    prlimit --pid=<PID> | grep -i cpu
    
    prlimit --pid=$(pidof -s sshd) | grep -i cpu
    prlimit --pid=$(pidof -s inetd) | grep -i cpu
    prlimit --pid=$(pidof -s telnetd) | grep -i cpu

    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-p3 (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 (1. Februar 2020 um 10:13)

    • Offizieller Beitrag

    Ist das ein PI4 oder ein PI3, mit Buster?

    Mit welchem Betriebssystem benutzt Du PuTTY?

    RPi4 und Win10 Pro. Aber stimmt, Win 10 erst seit ein paar Wochen. Ich könnte dann mal direkt per PowerShell eine Verbindung aufbauen und sehen ob es da auch etwas dauert.

  • Zitat

    BTW: Für die Fehlersuche ist nicht entscheidend ob eine funktionierende/brauchbare ssh- oder telnet-Verbindung zu deinem PI hergestellt werden kann, sondern ob der PI auf einfache Portscans (Ports 22 und 23) _aus dem (W)LAN_ antwortet oder nicht antwortet. Z. B.:

    OK, danke für den Hinweis. Werde ich das nächste Mal berücksichtigen :)

    Zitat

    Du hast doch "dtparam=act_led_trigger=heartbeat" auf deinem Pi konfiguriert, oder?

    Wenn ja, weißt Du dann wie die grüne Led am PI zu blinken hat? Das darf kein durchgängig gleichmäßiges Blinken sein. Kannst Du einen Unterschied im Blinken der grünen Led an deinem PI feststellen, sofort nach dem booten, wenn dein PI per ssh oder telnet noch erreichbar ist und zu einem Zeitpunkt wenn dein PI per ssh oder telnet nicht mehr erreichbar ist?

    Wenn der Raspberry auf der Seite liegt, blinkt die grüne LED recht schnell und durchgängig gleichmäßig. Das habe ich gestern abend geprüft. In den Tiefen des Internets habe ich jedoch keinen Hinweis zur Bedeutung gefunden.

    Wenn er normal läuft, also im Moment, blinkt er 2 mal schnell.

    Zitat

    Stromkabel ziehen ist nicht gut. Schreibe ein Script das auf dem PI (per cronjob oder timer-unit) prüft ob dieser von außen nicht mehr erreichbar ist, und wenn das der Fall ist dann soll sich der PI selber rebooten (so dass Du nicht immer das Stromkabel ziehen muss).

    Muss ich mir nachher mal anschauen, wie das funktioniert.

    Zitat
    prlimit --pid=<PID> | grep -i cpu  
     prlimit --pid=$(pidof -s sshd) | grep -i cpuErgebnis: CPU | CPU | time unlimited unlimited seconds

    prlimit --pid=$(pidof -s inetd) | grep -i cpuErgebnis: CPU | CPU | time unlimited unlimited seconds

    prlimit --pid=$(pidof -s telnetd) | grep -i cpuDen Telnet Daemon habe ich wieder entfernt, weil ich ihn eigentlich nicht mehr benötige.
  • Wenn der Raspberry auf der Seite liegt, blinkt die grüne LED recht schnell und durchgängig gleichmäßig. Das habe ich gestern abend geprüft. In den Tiefen des Internets habe ich jedoch keinen Hinweis zur Bedeutung gefunden.

    Wenn er normal läuft, also im Moment, blinkt er 2 mal schnell.

    BTW: Siehe auch die Ausgabe von:

    Code
    cat /sys/devices/platform/leds/leds/led0/trigger
    Zitat
    heartbeat Simuliert einen Herzschlag. Solange der Linux-Kernel läuft, blinkt die LED in einem Doppelpuls
    Zitat

    heartbeat Flash like a heartbeat (1-0-1-00000)

    Quellen:

    https://indibit.de/raspberry-pi-e…wr_led-act_led/

    https://raspberrypi.stackexchange.com/questions/6967…c-and-heartbeat


    EDIT:

    Versuch mal auch mit:

    Code
    # dtparam=act_led_trigger=heartbeat
    # panic               Flash on kernel panic
    dtparam=act_led_trigger=panic

    (statt dem "Herzschlag").

    ... und mit:

    in der "/etc/sysctl.d/my_sysctl.conf"-Datei (oder gleichwertige Datei). Nach diesen Eintragungen (inkl. speichern) musst Du deinen PI rebooten.

    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-p3 (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 (1. Februar 2020 um 13:00)

  • Hallo,

    mein Pi4 hatte das Problem, dass er nach ca. 1,5 Tagen nicht mehr erreichbar war.
    Mir viel aber auf, dass er noch laufen muss, denn die Zigbee-Geräte arbeiteten noch. Nur das Netzwerk war tot.

    Netzwerk über Ethernet.

    Ich habe irgendwann in den Syslogs einen Fehler des avahi Dienstes für Apples Bonjour gefunden.
    Ich habe den Deamon deinstalliert und jetzt läuft mein Pi4 schon mehr als 6 Tage ohne Probleme.

    sudo apt-get remove avahi-deamon

    Vielleicht ist das ja einen Versuch wert.

  • ... jetzt läuft mein Pi4 schon mehr als 6 Tage ohne Probleme.

    Wie muss man das "schon mehr als 6 Tage", verstehen? Gibt es danach noch Probleme und wenn ja, welche?

    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-p3 (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

  • Wie muss man das "schon mehr als 6 Tage", verstehen? Gibt es danach noch Probleme und wenn ja, welche?

    Es soll heißen: er läuft noch immer.
    Bisher ist der nach 1,5 Tagen nicht mehr zu gebrauchen gewesen.
    Nach dem deinstallieren von avahi läuft er aktuell schon 6 Tage und 5 Stunden ohne sich wieder aufzuhängen.
    Ohne Probleme. Mit Node-Red, Mosquitto MQTT Server und Deconz für Zigbee.

  • Bei mir war es am Ende ein ganz einfache Ursache. Der RAM war manchmal zu 100% ausgelastet. Leider hat der Raspberry sich auch nach langer Wartezeit nicht erholt. Habe nun einen Raspberry 4 mit 4 GB und keine Probleme mehr.

    Danke an alle Beteiligten für die gute Unterstützung bei der Fehlersuche.

  • Hallo Miteinander

    Ich besitze einen Raspi 4 mit 2GB auf dem Homeassistant mit raspian Buster lite laut dieser Seite läuft: Software

    Zwei Tage rennen lassen und dann von SD-Karte auf SSD-Boot am USB umgestellt (SD-Karte raus)

    In diesen zwei Tagen war der Zugriff via Putty immer möglich.

    Seit der Umstellung ist es so, daß der Raspi über LAN mit Putty (rfkill für WLAN -> laut skript) nach einiger Zeit (ein paar Stunden) nicht mehr zu erreichen ist.

    Dann hilft nur noch Stecker ziehen und der Zugriff ist wieder eine Zeit lang möglich.

    Der Raspi muss aber rennen, da ein RTL-SDR Stick dranhängt und die Daten der Wetterstation momentan als Test mitloggt.

    Wenn ich mir die Daten dann in Grafana anschaue, sind diese "durchgehend" und plausibel.

    Würde es was bringen, wenn ich die Infos von rpi444 umsetzen würde?

    Könnte es was anderes sein?

    vorab schon mal Danke

    willi

Jetzt mitmachen!

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