Pi3+ hängt sich nachts auf

  • Hallo zusammen,

    ich habe Anfang April meinen Pi3+ neu installiert (Debian 11) und habe seit dem 30 April folgendes Problem:

    Das OS hängt sich nachts immer zur selben Uhrzeit auf nur Nachts). Allerdings nicht jede Nacht sondern mal zwei Tage hintereinander mal nach mehreren Tagen. Aber immer um 06:25:03 Uhr, das zumindest ist der letzte Eintrag in der syslog. Habe hier mal die entsprechende Uhrzeit aus der Syslog der letzten drei Tage aufgeführt. Am 28. und 31 Mai gab es keinen Absturz, das Logfile geht direkt weiter, aber am 29. und 31. Mai hängt sich das System auf. Der Eintrag der folgt ist vom Neustart (daher auf eine Zeit früher als 06:23).

    Es wird irgendeine Systemd-Session gestartet, aber ich weiß nicht welche. Ich habe Systemd mit journalctl durchsucht, kann aber keinen EIntrag zu den Sessions finden. Der Pi reagiert zwar auf Ping-Anfragen aber nicht auf ssh-Anfragen. Beim Anschließen einer USB-Tastatur erfolgt keine Reaktion.

    Hat jemand eine Idee was es sein könnte, oder einen Vorschlag wie ich es herausfinden könnte?

    Informationen zum System:

    Das System ist auf einem USB-Stick installiert, es läuft Apache2 und die Nextcloud (Version 26).

    Die Temperatur beträgt ca 62°C.

    Die Speicherauslastung liegt bei ca 30%, Swap bei 15%.

    Raspi: 3+ B

    rpi-update wurde NICHT gemacht

    OS: Debian 11 (aktuell)

    Kernel: 6.1.21-v8+

    Release-Datum: Raspberry Pi reference 2023-02-21

    Angeschlossene USB-Geräte:

    Bus 001 Device 006: ID 0781:5583 SanDisk Corp. Ultra Fit

    Bus 001 Device 004: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s

    Bus 001 Device 005: ID 0781:5583 SanDisk Corp. Ultra Fit

    Bus 001 Device 007: ID 0424:7800 Microchip Technology, Inc. (formerly SMSC)

    Bus 001 Device 003: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub

    Bus 001 Device 002: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub

    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

    Gruß

    Levikus

  • Wie viele haben auf deinen nextcloud zugriff?

    Denn wenn einer auf Bilder oder Fotos zugreift wird dein 3B ziemlich in die Knie gehen und es wird extrem langsamer bis nicht mehr funzt.

    NExtcloud fertig von allen Bilder vorschau Bilder an und das könnte daran liegen, mein tip, schalte mal nextcloud offline.

    Dann beobachten.

    Abhilfe habe ich durch dieses Tutorial bekommen,


    EDIT: schau dir mal den Kern.log an

    Einmal editiert, zuletzt von gigagreen (31. Mai 2023 um 19:44)

  • Hallo gigagreen,

    es haben nur zwei Personen Zugriff auf die Cloud und die Frühstücken um diese Uhrzeit, also da kommen keine Daten.

    Im Kern.log findet sich auch nichts. Komischerweise beginnt er immer beim Booten (logisch) und endet mitten am Tag. Also keine Einträge abends oder nachts.

    Ich habe gerade mal in der Crontab nachgesehen und da wird täglich um 6:25 cron.daily ausgeführt. Evtl. ist es eines der Skripte von dort.

  • Der Adapter lief auf USB 2.0 einwandfrei, und da der TE einen RPi3B+ erwähnt hatte, habe ich erstmal keinen Laut gegeben.

    Gesehen hatte ich das schon.

    Hängt an dem Adapter eine Platte?

    Wenn nein, dann den Adapter abstöpseln.

    Wenn ja, erstmal vorübergehend abstöpseln und schauen ob der Fehler wieder auftaucht.

    MfG

    Jürgen

    Edit: Mit 06:25 würde ich auch erstmal auf ein amoklaufendes Cron-Script tippen

  • Nachtrag: Ich würde auch mal mit df -h nachsehen wie voll Dein Dateisystem ist.

    Kann natürlich auch sein das das Dateisystem mit Log-Dateien vollgelaufen ist.

    MfG

    Jürgen

    Der das auch schonmal hatte.

  • Hallo zusammen,

    hyle hier der Auszug aus /var/log/auth.log mit den beiden nachfolgenden Zeilen:

    Kann da keine Hinweise erkennen.


    Jürgen Böhm und Martin28 an dem Adapter hängt die ssd-Platte. Werde mal schauen, ob ich die abklemmen kann (weiß gerade nicht was darauf zugreift).

    Zitat von Jürgen Böhm

    Nachtrag: Ich würde auch mal mit df -h nachsehen wie voll Dein Dateisystem ist.

    Kann natürlich auch sein das das Dateisystem mit Log-Dateien vollgelaufen ist.

    Daran hatte ich auch schon gedacht, aber das Dateisystem ist nur zu 13% belegt. Daran wird es wohl nicht liegen.

    Aber nochmal zurück zu dem USB-Adapter:

    Ich habe in der Crontab den Zeitpunkt für /etc/cron.daily/ auf eine andere Zeit gesetzt und dann die Einträg in den logfiles mit tail -f beobachtet. Das Ausführen von locate dauert ja, verständlicher weise, ziemlich lange. Aber sobald dieses beendet ist wird in die syslog für die gestartete Session die verbrauchte CPU Zeit angezeigt.

    Dieser Eintrag fehlt, wenn der Pi sich aufhängt.

    Ich denke, dass dieses Skript für den Absturz indirekt verantwortlich ist. Denn wenn man dann noch den USB-Adapter berücksichtigt, mit Bezug auf

    Zitat von Martin28

    dieser USB-SATA-Adapter ist in Jürgen Böhm 's Liste hier: Magische USB-SATA Adapter und wo sie zu finden sind unter "bad" zu finden. Hab aber keine Ahnung, ob das mit deinem Problem zusammenhängt.

    dann ist es sogar wahrscheinlich das dieser zum Absturz führt. Ich werde mal den Adapter entfernen oder austauschen. Mal sehen was die nächsten Tage dann bringen.

    Gruß

    Levikus

  • schau mal in den Kern.log ob der raspi den Adapter neu startet, falls ja hast du deinen Fehler gefunden.

    Das selbe Problem hatte ich auch, dann bin ich auf USB-Stick umgezogen und nu rennt es einwandfrei

  • schau mal in den Kern.log ob der raspi den Adapter neu startet, falls ja hast du deinen Fehler gefunden.

    Das Problem ist, das die kern.log total zerfleddert ist. Es ist der Bootvorgang drin, dann mal eine paar Einträge ein paar Stunden später und dann nichts mehr. Ich sehe zu der fragliche Zeit keine Einträge. Auch in den Archiven findet sich nichts.

    Gruß

    Levikus

  • Ich werde mal den Adapter entfernen oder austauschen. Mal sehen was die nächsten Tage dann bringen.

    Hat es was gebracht, den Adapter auszutauschen?

    Was machst Du wenn der PI hängt bzw. abstürzt?

    Kommentiere mal temporär, in der crontab, die Einträge für:

    Code
    /etc/cron.hourly
    /etc/cron.daily
    /etc/cron.weekly
    /etc/cron.monthly

    und konfiguriere _persistent_:

    Code
    sudo sysctl -w vm.swappiness=1

    Wenn der Pi auf ping reagiert, ist er nicht abgestürzt. Es "hängt" dann evtl. der sshd. Funktioniert der Portscan auf den sshd?

    Code
    nc -zv <IP-Adresse-PI> 22

    ? Wenn nicht, dann mit einem Script+cronjob zum restarten des sshd, testen:

    Spoiler anzeigen
    Code
    59 6    * * *    root    /usr/local/bin/restart_sshd > /dev/null 2>&1
    Code
    #:~ $ cat /usr/local/bin/restart_sshd
    #!/bin/bash -e
    #
    if /bin/ps -fC sshd > /dev/null 2>&1; then
        exit 0
    else
        /bin/systemctl restart ssh
        exit 0
    fi
    exit 0

    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

  • Zitat von rpi444

    Hat es was gebracht, den Adapter auszutauschen?

    Ich habe den Adapter noch nicht getauscht. Habe vorher noch die SSD-Platte wo anders hingelegt. Da wo sie jetzt lag wurde sie sehr warm. Und bis jetzt läuft alles.

    Wenn der Pi auf ping reagiert, ist er nicht abgestürzt. Es "hängt" dann evtl. der sshd. Funktioniert der Portscan auf den sshd?

    Also, er reagiert auf ping, allerdings reagiert er auf keinen USB-Anschluss mehr, wenn ich z.B. eine Tastatur anschließe. Wenn ich wieder einen Monitor anschließe, dann blinkt auch der Prompt in der Konsole nicht mehr (habe keine grafisch Oberfläche). Daher denke ich, dass es nicht sshd ist.

    Einen Portscan werde ich beim nächsten mal versuchen.

    Was machst Du wenn der PI hängt bzw. abstürzt?

    Wenn er nicht mehr auf ssh reagiert ziehe ich den Stecker.

    Kommentiere mal temporär, in der crontab, die Einträge für:

    Code
    /etc/cron.hourly
    /etc/cron.daily
    /etc/cron.weekly
    /etc/cron.monthly

    Was meinst du mit "kommentiere"?

    Ich habe für alle Skripte in cron.daily Zeilen eingefügt, die mir in eine Logdatei Start- und Endzeitpunkte des jeweiligen Skriptes eintragen, wenn es ausgeführt wird. Beim letzten Hängen bleiben wurde locate gestartet aber nie beendet.

    und konfiguriere _persistent_:

    Code
    sudo sysctl -w vm.swappiness=1

    Habe ich gemacht. Was bringt mir das?

    Gruß

    Levikus

    Einmal editiert, zuletzt von Levikus (3. Juni 2023 um 17:21)

  • Wenn er nicht mehr auf ssh reagiert ziehe ich den Stecker.

    Das ist nicht gut.

    Versuch mal mit einem geeigneten selbst erstelltem Script und einem cronjob (oder timer unit), den PI von sich aus rebooten oder runterfahren zu lassen.

    Was meinst du mit "kommentiere"?

    Z. B. so:

    Code
    #17 *    * * *    root    cd / && run-parts --report /etc/cron.hourly
    #25 6    * * *    root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
    #47 6    * * 7    root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
    #52 6    1 * *    root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

    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

  • rpi ach, du meinst "aus"kommentieren. So kenne ich das. ;)

    Werde ich machen, wenn der Adaptertausch notwendig bzw. gemacht wurde.

    Gruß

    Levikus

    Einmal editiert, zuletzt von Levikus (5. Juni 2023 um 11:06) aus folgendem Grund: Rechtschreibung verbessert: Adapter tausche => Adaptertausch

  • Das ist nicht gut.

    Versuch mal mit einem geeigneten selbst erstelltem Script und einem cronjob (oder timer unit), den PI von sich aus rebooten oder runterfahren zu lassen.

    Ich habe jetzt Watchdog aktiviert, damit der Pi neu gestartet wird.

  • Eine Quelle wäre hier:

    Jürgen Böhm
    2. Juni 2020 um 13:35

    Aber welcher Adapter verwendet wurde interessiert mich auch.

    MfG

    Jürgen

  • Ich habe den Adapter noch nicht getauscht. Habe vorher noch die SSD-Platte wo anders hingelegt. Da wo sie jetzt lag wurde sie sehr warm. Und bis jetzt läuft alles.

    Also, ich habe tatsächlich nichts tauschen müssen (bisher).

    Seit dem Frühjahr liegen meine Pis im Flur in einem kleinen Telefonschränkchen mit meiner FritzBox und nem kleinen Switch. Dort lag die Platte unter einem Pi der in einem extra Gehäuse war und ihr wurde es anscheinend zu warm. Der Schrank hat zwar eine Belüftung, aber die reichte für diese Anordnung nicht. Jetzt liegt sie etwas exponierter, aber das scheint zu reichen. Vorher lagen die Pis offen im Raum, daher hatte ich nie Probleme mit der Temperatur.

    Mal sehen was der Sommer so bringt...

    Gruß

    Levikus

    Einmal editiert, zuletzt von Levikus (15. Juni 2023 um 08:20)

Jetzt mitmachen!

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