Pi ist am nächsten morgen nicht mehr aktiv obwohl er Strom hat?

  • Hallo zusammen,

    ich habe keine Ahnung warum mein Raspberry am nächsten morgen nicht mehr reagiert und quasi "stehen bleibt". Ich kann jedes mal nur den Stecker ziehen und neu booten lassen.

    Nachdem ich noch ein ziemlicher Neuling bin, hab ich trotzdem schon rausgefunden dass man eine Logfile auslesen kann. Natürlich verstehe ich diese noch nicht. Hier die Ergebnisse:

    Aug 5 06:25:49 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="8.$
    Aug 5 06:26:01 raspberrypi CRON[30098]: (www-data) CMD (php -f "/var/www/html/$
    Aug 5 06:27:01 raspberrypi rsyslogd0: action 'action 17' resumed (module 'buil$
    Aug 5 06:27:01 raspberrypi rsyslogd-2359: action 'action 17' resumed (module '$
    Aug 5 06:27:01 raspberrypi CRON[30171]: (www-data) CMD (php -f "/var/www/html/$
    Aug 5 06:28:02 raspberrypi CRON[30251]: (www-data) CMD (php -f "/var/www/html/$
    Aug 5 06:29:02 raspberrypi CRON[30332]: (www-data) CMD (php -f "/var/www/html/$
    Aug 5 06:30:01 raspberrypi CRON[30410]: (www-data) CMD (php -f "/var/www/html/$
    Aug 5 06:31:02 raspberrypi CRON[30531]: (www-data) CMD (php -f "/var/www/html/$
    Aug 5 06:32:01 raspberrypi CRON[30610]: (www-data) CMD (php -f "/var/www/html/$
    Aug 5 06:33:01 raspberrypi CRON[30688]: (www-data) CMD (php -f "/var/www/html/$
    Aug 5 06:34:01 raspberrypi CRON[30767]: (www-data) CMD (php -f "/var/www/html/$
    Aug 5 06:35:01 raspberrypi CRON[30847]: (www-data) CMD (php -f "/var/www/html/$
    Aug 5 06:36:01 raspberrypi CRON[30968]: (www-data) CMD (php -f "/var/www/html/$
    Aug 5 06:37:01 raspberrypi CRON[31041]: (www-data) CMD (php -f "/var/www/html/$
    Aug 5 06:38:01 raspberrypi CRON[31121]: (www-data) CMD (php -f "/var/www/html/$
    Aug 5 06:39:01 raspberrypi CRON[31210]: (www-data) CMD (php -f "/var/www/html/$
    Aug 5 06:39:01 raspberrypi CRON[31211]: (root) CMD ( [ -x /usr/lib/php5/sessi$
    Aug 5 06:40:01 raspberrypi CRON[31333]: (www-data) CMD (php -f "/var/www/html/$


    Könnt ihr daraus was ableiten?

    Ein dist-upgrade und auch das Update vom Kernel habe ich gestern erst gemacht.

  • Pi ist am nächsten morgen nicht mehr aktiv obwohl er Strom hat?? Schau mal ob du hier fündig wirst!

  • Bitte genauere Details:

    - Welcher PI
    - Welches Netzteil
    - Was ist an den PI angeschlossen?
    - Ist der PI übertaktet?
    - Wo steht der PI?
    - Geschlossenes Gehäuse? Wohl möglich sogar luftdicht?
    - Welches Images ist installiert?
    - Welcher Kernel?
    - Wie hast du den Kernel updated?
    - Was ist das für ein Script, welches da über CRON ausgeführt wird?

    Siehe dazu auch FAQ Bereich --> Mein Raspberry Pi stürzt ab / läuft instabil - woran kann das liegen?

  • - Welcher PI
    - Welches Netzteil
    - Was ist an den PI angeschlossen? -> WLAN USB, Bluetooth USB
    - Ist der PI übertaktet? -> Ja auf 900
    - Wo steht der PI? -> Auf einem Schreibtisch
    - Geschlossenes Gehäuse? Wohl möglich sogar luftdicht? -> PI Gehäuse mit Kühlern und Luftschlitzen
    - Welches Images ist installiert? -> Raspbian und dann mit dist-upgrade auf aktuellste Version von wheezy
    - Welcher Kernel? -> Wo sehe ich sowas?
    - Wie hast du den Kernel updated? -> mit raspbian-update hieß der Befehl glaub ich. Es war in jedem Fall der Kernel Update Befehl
    - Was ist das für ein Script, welches da über CRON ausgeführt wird? -> von dem PI Control http://willy-tech.de/pi-control-1-3-2/

  • ...wichtige Details hast du leider nicht beantwortet...


    Bitte zeig deine vollständige /boot/config.txt
    Tritt das Problem auch ohne Übertaktung auf?

    Kernel Version lässt du dir mit dem Befehl uname -a anzeigen

    Die über rpi-update installierten Kernels sind immer unstable und mit Vorsicht zu genießen. An diesen Kerneln wird aktuell gearbeitet und können selbstverständlich Fehlerhaft sein. Sobald ein Kernel als Stable eingestuft wird ist dieser auch wie alles andere über apt-get verfügbar.


    PI-Control scheint auch nicht so optimal zu sein - auf den ersten Blick fällt mir auf das es sehr viel (jede Minute) temporäre Dateien auf der SD schreibt, zur Anzeige der aktuellen Ram, Netzwerk, Cpu und Temperatur Werte... Das ist etwas seltsam gelöst. Die SD Karten vertragen aber nicht unendlich viele Schreibzugriffe... deshalb "nicht so optimal"

  • Gerade welches Modell und was für ein Netzteil wäre interessant, da solche "unbegründeten" Aussetzer oftmals zu wenig Strom ist. Da du WLAN und Bluethooth hast (beides Drahtlosmedien, welche gerne kurzfristig viel Strom brauchen) ist das ganze noch wahrscheinlicher.

  • Hi,
    eins vielleicht noch:


    ... ich habe keine Ahnung warum mein Raspberry am nächsten morgen nicht mehr reagiert und quasi "stehen bleibt". Ich kann jedes mal nur den Stecker ziehen und neu booten lassen.
    ...

    was heisst "stehen bleiben" ... hast Du einen Bildschirm und eine Tastatur angeschlossen?
    Wenn ich das recht verstanden habe, dann wohl nicht.
    Hast Du die Möglichkeit, mal eine Tastatur und einen Bildschirm anzustöpseln?
    Ich vermute stark, dass Dein Netzwerk weg ist (Spannungseinbruch am Netzteil).
    Aber dazu wäre, wie Meigrafd bereits geschrieben hat, der Typ des RPi wichtig zu wissen ...

    //EDIT: Horroreyes: zwei Deppen ein Gedanke ;)

    cu,
    -ds-

  • Also, ich habe ein Raspberry b+ Modell mit einem 2A Netzteil. Meine Bluetooth Maus und Tastatur sind durchgehend angeschlossen.

    Mit stehen bleiben rede ich davon dass ich am nächsten morgen den Bildschirm anmache, die Maus bewege, eine Taste drücke oder per SSH auf den Raspberry zugreifen will und er nicht erreichbar ist, obwohl das rote Lämpchen leuchtet. Ich habe ihn am Vorabend nicht in den Hold Modus oder dergleichen gebracht. Das meine ich damit.

  • # For more options and information see
    # http://www.raspberrypi.org/documentation/…n/config-txt.md
    # Some settings may impact device functionality. See link above for details

    # uncomment if you get no picture on HDMI for a default "safe" mode
    #hdmi_safe=1

    # uncomment this if your display has a black border of unused pixels visible
    # and your display can output without overscan
    disable_overscan=1

    # uncomment the following to adjust overscan. Use positive numbers if console
    # goes off screen, and negative if there is too much border
    overscan_left=1
    overscan_right=1
    overscan_top=1
    overscan_bottom=1

    # uncomment to force a console size. By default it will be display's size minus
    # overscan.
    #framebuffer_width=1920
    #framebuffer_height=1080

    # uncomment if hdmi display is not detected and composite is being output
    #hdmi_force_hotplug=1

    # uncomment to force a specific HDMI mode (this will force VGA)
    hdmi_group=1
    hdmi_mode=16

    # uncomment to force a HDMI mode rather than DVI. This can make audio work in
    # DMT (computer monitor) modes
    #hdmi_drive=2

    # uncomment to increase signal to HDMI, if you have interference, blanking, or
    # no display
    #config_hdmi_boost=4

    # uncomment for composite PAL
    #sdtv_mode=2

    #uncomment to overclock the arm. 700 MHz is the default.
    arm_freq=800

    # Uncomment some or all of these to enable the optional hardware interfaces
    #dtparam=i2c_arm=on
    #dtparam=i2s=on
    #dtparam=spi=on

    # Uncomment this to enable the lirc-rpi module
    #dtoverlay=lirc-rpi

    # Additional overlays and parameters are documented /boot/overlays/README

    core_freq=250
    sdram_freq=400
    over_voltage=0


    Ob das Problem auch ohne Übertaktung auftritt hab ich noch nicht ausprobiert. Werde ich heute über Nacht mal tun.


  • Die über rpi-update installierten Kernels sind immer unstable und mit Vorsicht zu genießen. An diesen Kerneln wird aktuell gearbeitet und können selbstverständlich Fehlerhaft sein. Sobald ein Kernel als Stable eingestuft wird ist dieser auch wie alles andere über apt-get verfügbar.

    Kann mir mal bitte irgendjemand eine Quelle nennen, in der das belegbar dargestellt ist?

  • Also über Nacht hatte er wieder diesen "Freeze". Heute morgen hat er weder auf Tastatur noch Maus noch SSH reagiert.

    Nur mal so als Gedanke, ich habe in meiner Fritzbox eine Downtime von meinem WLan von 1 Uhr nachts bis 7 Uhr morgens drinnen. Natürlich versuche ich erst ab ca 8 Uhr ob er reagiert. Kann das irgendwas auslösen? Und ich hatte heute nacht noch die Übertaktung mit 800 getestet, auch das werde ich jetzt mal auf 700 runterfahren.

    Dennoch würde mich das Kernel Thema sehr interessieren.


  • ... noch SSH reagiert.

    Nur mal so als Gedanke, ich habe in meiner Fritzbox eine Downtime von meinem WLan von 1 Uhr nachts bis 7 Uhr morgens drinnen. Natürlich versuche ich erst ab ca 8 Uhr ob er reagiert. Kann das irgendwas auslösen?

    Ja, ... dass z. B. zumindest evtl. keine default route mehr, in der Routen-Tabelle des PI, vorhanden ist.

    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 (6. August 2015 um 14:38)

  • m4soN: Kann es vielleicht sein das dein WLAN-Stick in den Standby geht? -> Ausschlussverfahren. Schließe alle möglichen Fehlerquellen aus indem du eins nach dem anderen änderst.
    Der nächste Schritt wäre also den PI über ein LAN-Kabel anzuschließen um WLAN als Fehlerquelle auszuschließen.
    Wenn die selbe Zeit vergangen is bei dem zuvor die Probleme auftraten kannst du den nächsten Schritt versuchen - der da wäre die über Nacht nicht benötigten USB Geräte abzuklemmen.
    Der nächste Schritt könnte sein ein anderes Netzteil auszuprobieren.

    Aber auch wirklich Schritt für Schritt, sonst weißt du später nicht mehr woran es lag.


    PS: Du schriebst der PI sei auf 900 MHz übertaktet, aber laut deiner config.txt ist er nur auf 800 MHz übertaktet, und greift auch erst dann wenn er ausgelastet wird.
    Bist du sicher das du die richtige config.txt gepostet hast?

  • Hallo meigrafd,

    ich habe hier sudo nano /etc/modprobe.d/8192cu.conf folgenden Wert eingetragen: options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

    Das soll laut Guide den Sleepmodus meines Sticks verhindern.

    Und ich hatte vorgestern noch auf 900mhz übertaktet, gestern auf 800mhz und jetzt auf Standard 700 damit ich weiß ob es daran liegt. Also ist es schon die richtige config.


  • ... in meiner Fritzbox eine Downtime von meinem WLan von 1 Uhr nachts bis 7 Uhr morgens ...

    Kannst Du evtl. im WLAN-Log deiner FritzBox etwas erkennen (... wenn die FB entsprechend konfiguriert ist)?

    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


  • Doofe Frage, was soll mir die Fritzbox dazu sagen? Es bleibt ja mein Raspberry hängen und reagiert auf nichts mehr.

    Wenn dein Raspberry per WLAN mit der FritzBox verbunden ist, dann kann dir die FritzBox (... bei entsprechender Konfiguration) z. B. sagen, ob der Raspberry sich aus dem WLAN (ordnungsgemäß) abgemeldet hat oder ob die FritzBox den Raspberry richtigerweise abgemeldet hat (... weil dieser z. B. nicht auf das rekeying (oder gleichwertig) der FritzBox geantwortet hat).

    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 (7. August 2015 um 10:52)

  • Also ich würde einfach mal die nächtliche Downtime der Fritzbox herausnehmen und schauen was passiert oder diese auf eine zeitnahe Tageszeit verlegen. So kommst du evtl. schneller diesbezüglich zu einem Ergebnis.

Jetzt mitmachen!

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