nach einigen Tagen kein Zugriff mehr auf den Pi möglich

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

    ich habe an meinem headless betriebenen Raspberry Pi 4 das Problem, dass er nach einer gewissen Zeit (bisher zwischen 4 und 8 Tagen) nicht mehr erreichbar ist.

    Der Fehler tritt jetzt scheinbar jedes Mal wieder auf, bisher insgesamt vier Mal. Ich bin mir nicht sicher, ob das Problem von Anfang an existiert hat. Der Pi ist noch recht neu und zu Beginn habe ich ihn wirklich recht häufig neu gestartet. Vielleicht ist es deshalb nicht zu diesem Problem gekommen. Startet man den Pi neu (mir bleibt nur Netzstecker ziehen), läuft danach tagelang alles wieder normal bis zum nächsten Fehler.

    Zunächst das System:

    - Pi 4 8Gb mit offiziellem Raspberry Pi (desktop) OS installiert auf SSD mit Imager (KEINE SD-Karte vorhanden!)

    - Das Netzteil ist ein original Raspberry Netzteil mit 15W (3A)

    - Die Temperatur liegt dauerhaft bei ca. 42°

    - Auslastung von RAM und CPU geht gegen Null (Anzeige im Pi-hole)

    Das läuft bisher auf dem Pi:

    - Pi-hole Ad-blocker

    - Pi-hole ist auch der DHCP-Server

    - lighttpd webserver wurde von Pi-hole mit installiert, diesen nutze ich zudem, um eine eigene kleine lokale html im Netzwerk zu hosten

    - PiVPN (Wireguard)

    Wenn das Problem auftritt, kann ich mich mit sämtlichen Methoden nicht mehr verbinden:

    - PuTTY SSH: "Network error: Software caused connection abort"

    - vnc Viewer: "Die Verbindung wurde unerwartet beendet"

    - pi-hole (lighttpd): "500 Internal Server Error"

    - smb: "der angegebene Netzwerkname ist nicht mehr verfügbar"

    Interessant ist jedoch, dass der Pi weiterhin angepingt werden kann, sowohl mit der festen IP als auch mit seinem hostname. Das Ad-blocking von Pi-hole funktioniert ebenfalls weiterhin. Er muss also noch aktiv sein, ist nur nicht erreichbar. Ich habe leider keinen Monitor da, um seinen Zustand auf diese Weise zu kontrollieren.

    Nachdem ich den Pi dann mit Netztstecker neu gestartet habe, sieht man, dass Pi-hole schon eine ganze Weile vorher aufgehört hat Einträge im Dashboard zu machen, obwohl Werbung noch geblockt wurde. Das ist auffällig. Somit ist der Moment rückverfolgbar, ab wann das Problem begonnen hat.

    Durch google Suche bin ich auf die log-Dateien des Pi aufmerksam geworden. In der /var/log/messages ist kurioserweise zu sehen, dass scheinbar ein kernel reboot stattgefunden hat, immer genau kurz BEVOR Pi-hole kein logging mehr gemacht hat (bevor???).

    Ich weiß nicht, ob wirklich ein Neustart stattgefunden hat, ich glaube es fast nicht. Wenn ich bewusst einen Neustart mache, funktioniert ja danach immer alles wie es soll. Außerdem passt es nicht, dass Pi-hole im Moment des vermeintlichen Neustarts laut Log noch mehrere Minuten weiter Werbung blockiert und erst dann der Log abbricht.

    Keine Ahnung was da passiert. Ich hoffe, jemand kann mir bei der Fehlerfindung helfen. Der Pi ist ein tolles Teil, aber als Prio 1 sollte er stabil laufen. Ich habe eigentlich noch einiges mit ihm vor, warte jetzt aber erstmal ab, bis dieses Problem (hoffentlich) gelöst ist.

    Vielen Dank im Voraus

    Gruß,:dau2:

    Nils

  • nach einigen Tagen kein Zugriff mehr auf den Pi möglich? Schau mal ob du hier fündig wirst!

  • Moin Pils,

    der RPi ist per Lankabel im Netz? Wenn ja, ist WLan auch aktiviert.

    dass scheinbar ein kernel reboot stattgefunden hat,

    Hast du mal einen Auszug?

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Ja, ist per Kabel im Netz. WLAN ist am Pi deaktiviert.

    Hier ein Auszug aus der messages Log-Datei. Am 13. Oktober um 13:17:06 sieht es für mich nach einer Boot-Sequenz aus.

    Der Log von Pi-hole läuft aber durch bis 13:23:52 und bricht dann erst ab!?

    Gruß,:dau2:

    Nils

  • Moin Pils,

    das sieht nach eine Reboot aus.

    Was steht den in /var/log/syslog zur fraglichen Zeit. Gerne auch etwas eher in der Zeit. Wegen Fehler...

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Ja, da ist etwas auffällig!

    Der letzte Fehlerzeitpunkt liegt in der gepackten Datei syslog.4. Wenn ich versuche diese Datei zu öffnen, bekomme ich einen Fehler wegen ungültiger Zeichenkodierung UTF-8. Alle anderen syslogs lassen sich problemlos öffnen.

    Ich habe die Datei auf Windows kopiert und dort mit np++ geöffnet, das ging (siehe unten).

    Zum Zeitpunkt des Fehlers zeigt mir np++ sehr viele NUL Zeichen an (746 um genau zu sein). Ich habe die Stelle händisch nachgetragen, weil es beim Kopieren hier in das Forum die NUL durch Leerzeichen ersetzt hat. Ich habe das Gefühl, wir kommen näher...

    Gruß,:dau2:

    Nils

  • - Pi 4 8Gb mit offiziellem Raspberry Pi (desktop) OS installiert ...

    Interessant ist jedoch, dass der Pi weiterhin angepingt werden kann, sowohl mit der festen IP als auch mit seinem hostname. Das Ad-blocking von Pi-hole funktioniert ebenfalls weiterhin. Er muss also noch aktiv sein, ist nur nicht erreichbar. Ich habe leider keinen Monitor da, um seinen Zustand auf diese Weise zu kontrollieren.

    Nachdem ich den Pi dann mit Netztstecker neu gestartet habe, ...

    Netzstecker ziehen ist nicht gut. Konfiguriere (mit einem shell-Script und cronjob oder gleichwertig) deinen PI so, dass der PI nach dem Ziehen des Lan-Kabels, dein PI nach z. B. 5 Minuten, richtig/kontrolliert runter fährt.

    Konfiguriere den PI auch so, dass auf den aktiven/lauschenden sshd regelmäßig (z. B. alle 6 Stunden) geprüft wird und bei Bedarf, der sshd neu gestartet wird.


    BTW: Wenn Du kein Monitor benutzt, warum hast Du die Desktop-Version installiert?

    Poste mal von deinem PI die Ausgaben von:

    Code
    sudo netstat -tulpena
    free -m

    Poste auch einen Portscan auf den lauschenden Port (22?) des sshd, wenn der sshd, mit deinem ssh-Client (Putty) aus den LAN nicht mehr erreichbar 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

  • Das mit den Skripten ist sicherlich eine gute Idee. Danke für den Vorschlag. Das eigentliche Problem wird dadurch leider nicht gelöst.

    Ich nutze den Desktop gerne und regelmäßig mit dem vnc viewer.

    Code
                  total        used        free      shared  buff/cache   available
    Mem:           7897         179        5948          40        1769        7393
    Swap:            99           0          99

    Poste auch einen Portscan auf den lauschenden Port (22?) des sshd, wenn der sshd, mit deinem ssh-Client (Putty) aus den LAN nicht mehr erreichbar ist.

    Wie geht das? Mit Putty selbst?

    Gruß,:dau2:

    Nils

  • Das mit den Skripten ist sicherlich eine gute Idee. .... Das eigentliche Problem wird dadurch leider nicht gelöst.

    Wie geht das?

    Die Scripte sollen ja das mit dem "Netzstecker ziehen", lösen.

    Ich mache das mit z. B. nc oder mit nmap:

    Spoiler anzeigen
    Code
    :~$ nc -zv 213.##.##.4 22
    Connection to 213.##.##.4 22 port [tcp/ssh] succeeded!
    Code
    ~$ sudo nmap -sS 213.##.##.4 -p22
    
    Starting Nmap 6.40 ( http://nmap.org ) at 2021-10-17 19:21 CEST
    Nmap scan report for xxxxxx (213.##.##.4)
    Host is up (0.032s latency).
    PORT   STATE SERVICE
    22/tcp open  ssh
    
    Nmap done: 1 IP address (1 host up) scanned in 0.72 seconds

    Das ist aber von den OSs die Du hast, abhängig.

    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

  • Die Scripte sollen ja das mit dem "Netzstecker ziehen", lösen.

    Ja, das habe ich verstanden. In diese Situation komme ich ja erst durch das Grundproblem mit der verlorenen Verbindung zum Pi. Wenn das gelöst würde, brauche ich den Stecker auch nicht mehr ziehen.

    Beim nächsten Ausfall werde ich mal mit nmap die Ports scannen.

    Gruß,:dau2:

    Nils

  • In diese Situation komme ich ja erst durch das Grundproblem mit der verlorenen Verbindung zum Pi. Wenn das gelöst würde, brauche ich den Stecker auch nicht mehr ziehen.

    Nein, nicht nur durch das "Grundproblem". Es kann auch andere Gründe immer mal geben, warum der PI nicht mehr erreichbar ist. Bei allem meinen PIs die ich headless betreibe und unabhängig vom OS, habe ich so einen cronjob, der greift wenn ich das Lan-Kabel aus dem PI entferne/ziehe.

    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

  • Moin Pils,

    in deinem Logauszug kann man erkennen, das was passiert ist. Aber da anscheinend nicht mehr in das syslog geschrieben wurde...

    Du könntest nun noch in den anderen Logs nachsehen. Als erstes würde ich mir /var/log/kern.log vornehmen.

    Ach, bist du per Lan oder Wlan verbunden??

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Als erstes würde ich mir /var/log/kern.log vornehmen.

    In dieser Datei ist nur wieder der Bootvorgang zu sehen, wie auch in der messages Log-Datei. Ein Grund für den Boot sehe ich dort nicht.

    Wenn der Pi wirklich neu bootet, warum unterscheidet sich der Boot von einem, den ich selbst bewusst durchführe? Nach einem bewusst durchgeführten Boot funktioniert immer alles.

    Der Pi ist mit Kabel im Netzwerk.

    Gruß,:dau2:

    Nils

  • Moin Pils,

    naja, man könnte sagen: Warmstart != Kaltstart

    Ich kann auch nur im Nebel stochern.

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

    Einmal editiert, zuletzt von Bernd666 (17. Oktober 2021 um 23:22)

  • Hier mal die deamon.log

    Auch in diesem Log findet man die NUL Einträge. Alles davor sieht für mich aber in Ordnung aus.

    Gruß,:dau2:

    Nils

  • Moin Pils,

    hast du ein Verzeichnis /var/log/lighttpd ? Ist da was zu sehen. Ich habe da eine error.log.

    Der Fehler passiert bei dem Aufruf die php-dateien zu prüfen. Solltest du mal checken, beim nächsten Fehler.

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • hast du ein Verzeichnis /var/log/lighttpd ? Ist da was zu sehen.

    Ja, da ist etwas zu sehen. Sieht für mich aber nicht nach kritischen Fehlern aus.

    Code
    2021-10-10 00:00:45: (server.c.1759) logfiles cycled UID = 0 PID = 14679 
    2021-10-13 13:17:07: (server.c.1464) server started (lighttpd/1.4.53) 
    2021-10-13 13:17:07: (server.c.1493) WARNING: unknown config-key: alias.url (ignored) 
    2021-10-15 22:41:08: Session expired! Please re-login on the Pi-hole dashboard.

    Der Fehler passiert bei dem Aufruf die php-dateien zu prüfen.

    Bin mir da nicht so sicher. Die Abfolge im Log ist immer die gleiche. Was lässt dich das glauben?

    Mal eine grundsätzliche Frage. Wie wahrscheinlich ist es, dass ein Software- bzw. Anwendungsfehler ein Neustart in dieser Form auslöst? Das einzige, das aus meiner Sicht dafür spricht, ist die recht lange Dauer bis zum nächsten Fehler. Als würde irgendetwas "volllaufen" oder "überlaufen".

    Wenn es Hardware wäre, sollte es rein zufällig passieren. Also auch mal kurz nach dem letzten Neustart und nicht erst wieder mehrere Tage später... :conf:

    Gruß,:dau2:

    Nils

  • Moin Pils,

    Der Fehler passiert bei dem Aufruf die php-dateien zu prüfen. Solltest du mal checken, beim nächsten Fehler.

    Bitte beide Sätze als Ganzen verstehen. Ob es beim nächsten Restart auch wieder so aussieht.

    keine Ahnung ob da Speicher gefressen wird, sollte sich aber in einem Log zeigen.

    Ansonsten was einbauen , Z.B.: free -h >> speicher.log. Das in die Systemcrontab alle paar Stunden aufrufen.

    Ich denke das man einfach Zeit braucht um eine Regelmässigkeit des Fehlers zu erkennen.

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

Jetzt mitmachen!

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