Raspberry sporadisch "ausgeschaltet"..

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Moin,

    Mein pi 2 b macht irgendwie was er will.. =(

    Ich habe Immer wieder das Problem, dass mein pi nach einer gewissen zeit (die zwischen weniger stunden und ein paar Tagen schwankt) einfach wie ausgeschaltet ist.
    Bild am pi ist dann schwarz, Service laufen nicht mehr, also auch nicht mehr extern erreichbar, keine led blinkt (nur die power led leuchtet dauerhaft).
    Der pi lässt sich Danuch nicht mehr mit pin 5 gegen Masse starten. Das einzige was hilft ist, kurz vom Strom trennen - anschließend startet er dann wieder ganz normal und läuft eine gewisse zeit.. Wie lang ist wie gesagt sehr dynamisch.

    Auch die zeit wann er nicht mehr erreichbar ist, ist unterschiedlich. Meist jedoch irgendwann in der nacht. Kann aber auch mal tagsüber passieren.

    Ich bin mir sicher, dass der pi nicht "ordnungsgemäß" herunterfährt, da ich eine push Benachrichtigung aufs Handy bekomme, wenn sich der pi ein oder ausschaltet (cronjob). (Diese push Benachrichtigung bleibt in dem Falle aus..)

    Leider hab ich mit Unix bisher relativ wenig Erfahrung.. :(
    Hat jemand einen tipp in welche Logs ich mal ein Auge werfen könnte um das Problem eingrenzen zu können?
    Oder ein Vorschlag wie ich das ganze debuggen könnte..

    Bin für jeden tipp dankbar. Wenn ich noch irgendwelche Daten, Logs, o.ä. Liefern kann, bitte einfach bescheid geben.

    Achja, ich nutze ein meanwell 5V 16A Netzteil, also mehr als genug Leistung ^^
    Die Ausgangsspannung habe ich auf genau 5.00V eingestellt.

    Danke und viele grüße

  • hm.. seltsam..
    dort ist der letzte Eintrag von 17:17 Uhr heute. Ich musste den Pi aber heute kurz nach 18:30 Uhr neustarten weil er sich mal wieder verabschiedet hatte.. :s

    "syslog"

  • hm.. seltsam..
    dort ist der letzte Eintrag von 17:17 Uhr heute. Ich musste den Pi aber heute kurz nach 18:30 Uhr neustarten weil er sich mal wieder verabschiedet hatte..

    Für mal auf deinem PI, nur als Test:

    Code
    sudo kill $(pidof cron) && ps -fC cron


    aus und schreib mit nano in die "/etc/rc.local", vor die Zeile "exit 0", Folgendes:

    Code
    /usr/bin/logger "reboot"

    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

  • Hi real_Napster,
    also von der Erfahrung mit dem Pi Modell B ist so was meist irgendein Problem mit der Stromversorgung. Du schreibst zwar ...


    ...
    Achja, ich nutze ein meanwell 5V 16A Netzteil, also mehr als genug Leistung ^^
    ...


    aber da kommt es immer drauf an, wie der RPi versorgt wird.
    Das Modell 2 ist, im Gegensatz zum Modell 1, scheinbar mit einer 2A Polyfuse ausgestattet. Aber mehr gaht dann da auch nicht durch, wenn die Speisung über die micro-USB-Buchse erfolgt.
    Inwieweit beim neuen RPi jetzt eine Versorgung per Rückeinspeisung über USB möglich ist, entzieht sich leider meiner Kenntnis.
    Aber evtl. kannst Du ja dadurch Abhilfe schaffen, indem Du die 5V direkt auf dem GPIO-Header anschliesst.

    cu,
    -ds-


  • Was bewirkt die Zeile?

    Mit:

    Code
    sudo cat /var/log/syslog | grep -i logger


    kann man danach, jederzeit m. E. bequem nach reboots schauen.

    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


  • Jetzt heißt es wohl warten bis er sich wieder aufhängt?

    Ja.

    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

  • :@ heute morgen war er schon wieder tot.....

    ich glaube allerdings, dass wir mit der syslog nicht weiter kommen...
    So wie ich das sehe ist da garkein neuer Eintrag!?:s:huh:

    die aktuelle syslog:

    "syslog"

    die Einträge von 20:00 Uhr kommen meines erachtens aber von einem geplanten reboot gestern abend.

    Warum danach keine Einträge mehr vorhanden sind (habe ihn ja jetzt vor ein paar Minuten erst wieder gestartet) kann ich mir nicht erklären....


    Viele Grüße


  • die Einträge von 20:00 Uhr kommen meines erachtens aber von einem geplanten reboot gestern abend.

    Warum danach keine Einträge mehr vorhanden sind (habe ihn ja jetzt vor ein paar Minuten erst wieder gestartet) kann ich mir nicht erklären....

    Wie sind jetzt auf deinem Pi, die Ausgaben von:

    Code
    date
    Code
    ls -ls /var/log | grep -i syslog


    ?

    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

  • Code
    pi@RealPi ~ $ date
    So 29. Mär 13:10:15 CEST 2015

    und

    Code
    pi@RealPi ~ $ ls -ls /var/log | grep -i syslog
     136 -rw-r----- 1 root adm   139080 Mär 28 20:00 syslog
      84 -rw-r----- 1 root adm    85791 Mär 28 06:25 syslog.1
      12 -rw-r----- 1 root adm     9760 Mär 26 06:25 syslog.2.gz
       4 -rw-r----- 1 root adm      452 Mär 24 06:25 syslog.3.gz
      16 -rw-r----- 1 root adm    13593 Mär 23 06:25 syslog.4.gz
      12 -rw-r----- 1 root adm     9946 Mär 21 06:25 syslog.5.gz
       4 -rw-r----- 1 root adm      445 Mär 20 06:25 syslog.6.gz
       4 -rw-r----- 1 root adm      445 Mär 19 06:25 syslog.7.gz

    Viele grüße

  • Code
    pi@RealPi ~ $ ls -ls /var/log | grep -i syslog
     136 -rw-r----- 1 root adm   139080 Mär 28 20:00 syslog

    Mit z. B.:

    Code
    dmesg -T


    kannst Du auch das Datum/Uhrzeit anzeigen lassen. Evtl. auch jetzt:

    Code
    sudo shutdown -r now


    (oder gleichwertig) ausführen und die Ausgaben erneut anschauen, nicht dass evtl. an der Konfiguration deines Pis etwas geändert worden 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 (29. März 2015 um 13:17)

  • "Ausgabe dmesg -T"

    und die neue syslog nach dem reboot:

    "syslog"


    EDIT: falls das gemeint war noch die ausgabe vom dmesg -T nach reboot

    "dmesg -T nach reboot"
  • D. h., immer wenn Du deinen "ausgeschalteten" Pi (neu)startest, gibt es keinen syslog-Eintrag? Das ist m. E. aber schon etwas seltsam.

    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

  • Ich möchte nur mal anmerken das 'dmesg' nach einem Reboot nur die aktuellen Informationen beinhaltet, aber keine von davor. Also wenn das System wegen was auch immer crasht und neu startet, kann über den Befehl 'dmesg' keine Rückschlüsse auf das Wieso gezogen werden da dazu keine Informationen angezeigt werden.

    Auch kann es gut sein das selbst in syslog oder messages nichts drin steht, da dieser Dienst einfach nicht die Gelegenheit hatte einen (Software)Fehler zu erkennen oder gar diesen ins Logfile zu schreiben, insbesondere dann nicht wenn man den Pi einfach ausschaltet da die Software nicht mehr reagiert..

    Der Beschreibung des TE's würde ich erst mal hinterfragen wie er seinen PI konfiguriert/eingestellt hat - also ob dieser zB übertaktet ist, wie seine /boot/config.txt aussieht, was der macht wenn er denn was machen soll (Scripts o.ä.), ob er in einem Gehäuse untergebracht ist, ob er den BCM-Watchdog eingerichtet hat usw...
    Aber bisher wurden nur Fragen zum Netzteil o.ä. gestellt, was ich persönlich aber als Quatsch empfinde da der Pi selber nicht neustartet o.ä.


    Ich habe Immer wieder das Problem, dass mein pi nach einer gewissen zeit (die zwischen weniger stunden und ein paar Tagen schwankt) einfach wie ausgeschaltet ist.
    Bild am pi ist dann schwarz, Service laufen nicht mehr, also auch nicht mehr extern erreichbar, keine led blinkt (nur die power led leuchtet dauerhaft).

    Der pi lässt sich Danuch nicht mehr mit pin 5 gegen Masse starten. Das einzige was hilft ist, kurz vom Strom trennen - anschließend startet er dann wieder ganz normal und läuft eine gewisse zeit.. Wie lang ist wie gesagt sehr dynamisch.

    Auch die zeit wann er nicht mehr erreichbar ist, ist unterschiedlich. Meist jedoch irgendwann in der nacht. Kann aber auch mal tagsüber passieren.

    Ich bin mir sicher, dass der pi nicht "ordnungsgemäß" herunterfährt, da ich eine push Benachrichtigung aufs Handy bekomme, wenn sich der pi ein oder ausschaltet (cronjob). (Diese push Benachrichtigung bleibt in dem Falle aus..)

    Warum sollte er auch? Sagst du ihm denn das er herunterfahren soll? :s


    (und was soll das überhaupt immer mit 'grep -i' ? es gibt nur "syslog" kein "Syslog" o.ä.)


  • Der Beschreibung des TE's würde ich erst mal hinterfragen wie er seinen PI konfiguriert/eingestellt hat - also ob dieser zB übertaktet ist, wie seine /boot/config.txt aussieh


    Taktung ist soweit ich mich erinnere die Standart Pi2 (1000Mhz)
    meine Config.txt schaut wiefolgt aus:

    "config.txt"


    [...] was der macht wenn er denn was machen soll (Scripts o.ä.)


    der Pi macht in 1. Linie Ambilight mit Hyperion

    Scripte die dauerhaft laufen:
    - ein FHEM Server

    "Temperaturabhängige Lüftersteuerung"
    "LCD Display"
    "Script zum Herunterfahren via Taster"
    "Push und optische Anzeige wenn jemand an der Tür klingelt"
    "Push Benachrichtigung bei Boot / Shutdown"


    Warum sollte er auch? Sagst du ihm denn das er herunterfahren soll? :s


    Das zwar nicht, aber daher kann ich mit Sicherheit sagen, dass zb das Shutdown script sich nicht selbstständig macht..
    Wollte damit nur sagen, dass es kein sauberes Herunterfahren sein kann.



    [...]ob er in einem Gehäuse untergebracht ist


    ja, allerdings in einem (noch) offenen und mit Lüftersteuerung (siehe oben)
    Aktueller Aufbau:



    [...]ob er den BCM-Watchdog eingerichtet hat


    äääähhh...:s
    Na, jedenfalls nicht Bewusst.. :lol:


    Ich hoffe das hat alle Fragen beantwortet.. :D

    achja eins vielleicht noch..
    meine rc.local sieht aktuell so aus:

    "rc.local"


    shutdown.py = herunterfahren via Taster
    klingel.py = push / optische anzeige beim Klingekn
    temperature.py = Lüftersteuerung
    power.py = Push Benachrichtigung beim booten


    Viele Grüße

  • 1000MHz sind nicht Standard. Standard wäre gar keine manuelle Anpassung sodass er im Idle auf 600 und unter Last auf 900MHz laufen würde.
    Deine Übertaktung könnte also durch aus eine Ursache sein

    Code
    arm_freq=1000
    
    
    start_x=0
    core_freq=500
    sdram_freq=500
    over_voltage=2

    Kommentier das also mal aus, reboote und beobachte dann ob dein Problem dann immer noch auftritt.


    Das von dir verwendete Lüftersteuerung's Script verursacht einiges an Last, aufgrund von vcgencmd und dem zweifachen Aufruf dieses. Ich hatte dir schon mal geraten das zu ändern.. Warum haste das nicht umgesetzt? :s



    Das zwar nicht, aber daher kann ich mit Sicherheit sagen, dass zb das Shutdown script sich nicht selbstständig macht..
    Wollte damit nur sagen, dass es kein sauberes Herunterfahren sein kann.

    Um das mit Gewissheit sagen zu können müsstest du die Logdateien vom Vorherigen Betrieb prüfen. Also nicht das aktuelle sondern das vor dem letzten "gezwungenen neustart". 'dmesg' wird wie gesagt bei jedem Boot neu erstellt, darin nach zu gucken ist also Sinnlos. 'syslog' wird i.d.R. ebenfalls mindestens jeden Tag neu erstellt (oder schneller sofern die Datei zu groß wird), also müsstest du wenn dann in die älteren Dateien reingucken, das letzte erhält die Dateiendung '.1' und die davor werden mit gzip gepackt.



    ja, allerdings in einem (noch) offenen und mit Lüftersteuerung (siehe oben)

    Nur protokollierst du nicht wie warm er wird und wann/ob sich der Lüfter einschaltet, oder? Deine print Zeilen sind auskommentiert aber enthalten auch keine Zeitangaben, also ließe sich so nicht nachvollziehen wie warm der SoC wird und ob der Lüfter überhaupt ausreichend kühlt - in deinem Gehäuse ist auch noch ne menge anderes Zeuchs was Wärme abgibt, vielleicht reicht der Lüfter nicht um den Pi ausreichend zu kühlen bzw die Wärme allgemein abzuführen, und dann schmiert der Pi halt irgendwann ab weil er zu heiß wird? :s

    Also noch mal: Ich hab dir schon mal geraten das Script zu ersetzen - vorzugsweise mit dem von mir, denn dann wird dir auch genau ausgegeben wie warm er aktuell ist und auch ne Zeitangabe ausgegeben etc. Das lässt du dann in einem Screen laufen, oder leitest die Ausgaben in eine Datei um, oder baust das logging Module ein...



    äääähhh...:s
    Na, jedenfalls nicht Bewusst.. :lol:

    Der BCM-Watchdog könnte bei falscher Konfiguration dazwischen funken. Leider gibt es da ein paar Einstellungen die imho Schwachsinn sind aber einige glauben sie müssten das nutzen.
    Richtig konfiguriert kann dieser Broadcom-Watchdog ein Hard-Reset durchführen wenn die Software nicht mehr reagiert.

    Allerdings solltest du jetzt nicht stumpf das Teil einrichten, denn dadurch wird Dein Problem nicht behoben sondern nur umgangen und ignoriert, das Problem bestünde dann aber weiterhin!



    meine rc.local sieht aktuell so aus:

    "rc.local"

    Wieso steht das denn alles in einer Zeile? :s
    Und was macht das sudo da? Die Datei wird bereits als root ausgeführt

    Und was soll '/usr/bin/logger "reboot"' da? /etc/rc.local wird nicht bei reboot ausgeführt sondern nur am Ende eines Bootvorgangs.

Jetzt mitmachen!

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