Pi nicht mehr per Netzwerk erreichbar, aber aktiv

  • Hallo!

    Ich habe mit meinem Pi das kleine bekannte Problem, daß er manchmal nicht mehr per Netzwerk erreichbar ist, aber anscheinend noch aktiv ist.

    Die Situation: mein Pi hängt als "kopfloser" Server hinter meiner FritzBox und ist per DynDNS von außen erreichbar. Manchmal bleibt er scheinbar grundlos stehen und will nicht mehr.

    Zuerst fiel mir auf, daß diese Stillstände immer nach der der Benutzung von apt-get oder aptitude auftraten und ich hatte das USB-Speicherzäpchen in Verdacht, das bei Benutzung auch reichlich warm wurde, was auf viel Strom hindeutet. (Siehe Ansturz nach Benutzung von apt-get oder aptitude)

    Jetzt habe ich eine 16GB-SD-Karte, und die vorher auf dem USB-Speicher abgelegten Daten befinden sich auf einer zweiten Partition auf der Karte. Danach lief der Pi ein paar Tage ohne Probleme stabil durch.

    Jetzt bleibt er wieder einfach stehen und ist nicht mehr ansprechbar.

    AAAAABER!!!!

    Ich habe eine alte USB-Maus angeschlossen, damit ich mit Hilfe von gpm, dem universellen Mausprogramm, den Pi sauber runter fahren kann, sollte es nötig sein. (Siehe https://www.forum-raspberrypi.de/Thread-tutoria…=70137#pid70137)

    Und das Interessante dabei: wenn ein solcher Stillstand kommt, kann ich den Pi trotzdem noch über eines der speziellen Maussignale (Dreifachklick) runterfahren und/oder neu starten.

    Das muss doch bedeutet, daß der Pi eigentlich noch arbeitet, wenn er nicht erreichbar ist. Oder?

    Ich weiß, ich könnte es einfach ausprobieren, aber es ist eine verdammt unbequeme Räumerei hier mit den Kabeln, wenn ich einen Monitor und eine Tastatur anschließen will. Daher frage ich erstmal in die Runde, ob meine Vermutung überhaupt richtig sein kann, oder ob es sein kann, daß die Maussignale von gpm noch an den Kernel gelangen, wenn der Pi ansonsten nicht mehr reagiert. Es gibt ja auch spezielle Tastatursignale, die bei einem abgestürzten Linux-Kernel noch etwas auslösen können. Geht das auch bei der Maus?

    Es könnte aber auch sein, daß der Netzwerk-Chip eine Macke hat. Im Syslog habe ich dazu bisher allerdings keine Meldung gefunden. (Kabel habe ich schon ausgetauscht.) Wie kann ich das evtl testen? Gibt es spezielle Testprogramme für so etwas?

    Als weitere Möglichkeit, die mir aber die unangenehmste wäre, käme ein Defekt meiner FritzBox in Frage.

    Als erste Maßnahme habe ich jetzt einen Cronjob installiert, der alle 5 Minuten einen Zeitstempel in eine Datei schreibt und ein sync macht, damit die Datei auch geschrieben wird. Jetzt warte ich im Prinzip auf einen Stillstand, um dann zu sehen, ob der Pi noch weiterarbeitet, während er nicht mehr erreichbar ist.

    Wer hat denn ein ähnliches Phänomen mit dem Pi erlebt? Gibt es Leidensgenossen?

  • Hallo,

    ich hatte im Herbst einen ähnlichen Effekt.

    Der Pi war urplötzlich über SSH nicht mehr erreichbar, funktionierte aber ansonsten noch. Über Webmin hatte ich noch Kontakt, habe ihn runtergefahren (reboot). Nach dem Hochfahren hat er dennoch keine Kontaktaufnahme über SSH erlaubt. Danach noch einmal runterfahren (shutdown), Strom aus, einige Minuten warten, Strom wieder an und noch immer keine SSH Verbindung.

    Ich habe dann ein auf dem Win-PC gespeichertes Image (Stand nach letzter Änderung) wieder auf die Karte getan. Danach hat er wie immer funktioniert.

    Die Sache war damit für mich erledigt. Ich hatte keine Zeit Ursachenforschung zu betreiben und wusste auch nicht wie.

    Mit lieben Grüßen
    Bracew


  • Als erste Maßnahme habe ich jetzt einen Cronjob installiert, der alle 5 Minuten einen Zeitstempel in eine Datei schreibt ...


    Du könntest auch einen Ping auf die int. IP-Adresse des Routers (evtl. mit dem watchdog) machen lassen.

    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

  • Leider schon wieder Stillstand. :(

    Diesesmal passierte es, als ich in Dokuwiki, das auf dem Pi läuft, eine kleine Bilddatei (~15kb) hochladen wollte. Ich hatte auf einer Shell (ssh) ein "top -c" laufen, und das letzte Bild vor dem Stillstand sah so aus:

    Wie man sieht, ist der Pi nicht wirklich ausgelastet mit dieser Aufgabe. Hinzu kommt, daß ich die CPU auf 600MHz getaktet habe.

    Der Effekt: der Pi reagierte nicht mehr auf Verbindungsversuche, jedes "ssh" wurde mit "No route to host" beantwortet. Gleichzeitig blinkte aber die LED für die Netzwerkschnittstelle sehr hektisch. Außerdem war es möglich, den Pi über die speziellen Mauskommandos (mit gpm) herunterzufahren.

    Bleibt eigentlich nur eine Schlussfolgerung: die Netzwerkschnittstelle macht schlapp. Was aber zur nächsten Frage führt: warum? Reicht die Stromversorgung nicht? Hat der Pi insgesamt eine Macke, sollte ich ihn umtauschen?

    Als nächstes werde ich ausprobieren, was passiert, wenn ich eth0 nicht im Vollduplex betreibe. Vielleicht verträgt sich die Netzwerkeinstellung auch nicht mit meinem Router. Ich könnte auch die Geschwindigkeit auf 10MBit drosseln, denn mit 100MBit ist der Pi von außen sowieso nicht erreichbar. (DSL).

    Weiß jemand, welche Argumente ich dafür in die module.conf schreiben muss?

  • Hallo Pinguin,

    ich habe einen ähnlichen Fehler bei mir beobachtet und festgestellt, dass
    a) dieser Fehler weit verbreitet ist
    b) möglicherweise viele berichtete Ausfälle eine gemeinsame - noch zu identifizierende - Ursache haben

    Ich habe ein Programm geschrieben, dass die beiden mir bekannten Dateien "repariert" und dadurch wieder eine Verbindung herstellt.

    Mich würde es sehr interssieren ob es bei Dir vielleicht der gleiche Hintergrund ist.

    Hier der Link auf meine Lösung.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    2 Mal editiert, zuletzt von Andreas (8. Oktober 2017 um 12:41)

  • Danke für Deine Antwort.

    Daß der Fehler etwas mit dem Netzwerk zu tun hat, habe ich mir nach dem letzten Stillstand auch schon gedacht. Wenn es aber so wäre, wie Du vermutest, müsste es reichen, regelmäßig ein "/etc/init.d/networking restart" auszuführen.

    Allerdings kommt der DHCP nicht als Ursache in Frage, da mein Pi eine feste IP hat.

    Ich habe jetzt, wie vorhin schon erwähnt, in /etc/rc.local den Befehl "/sbin/mii-tool -F 10baseT-HD" geschrieben. Ich halte es durchaus für möglich, daß der Netzwerk-Controller bei bestimmten Operationen aufgrund der schon häufiger erwähnten schlechten Stromversorgung zusammenbricht. Darum habe ich den jetzt erstmal gedrosselt. Mal sehen, was jetzt (nicht) passiert.

    dreamshader schrieb:

    Zitat

    Alternative, die ich evtl. noch akzeptieren könnte: den watchdog aktivieren und damit überwachen/rebooten.

    Welcher Wachhund ist damit gemeint? Kann mir jemand einen Hinweis oder Link geben?

  • Schau dir mal in dem erwähnten Thread meine Kommentare an... + meine Analyse der Log-Files von Andreas. Vielleicht hilft dieser Denkansatz weiter...

    PS: Auch eine fixe IP Adresse hilft nicht, wenn der eth0 abgeschaltet wird und nicht reinitialisiert wird...

    Deine Idee mit dem regelmäßigen Netzwerkstart ist nicht die schlechteste... u.U. wird aber gerade im falschen Moment eine laufende Verbindung unterbrochen... muss man wollen..
    Besser wäre vermutlich, einfach ein periodisches Ping auf eine bekannte IP (Router z.B.), wenn keine Antwort, dann Netzwerk-restart...

  • Ich lasse jetzt jetzt folgendes Skript alle 5 Minuten laufen:

    Und das werde ich jetzt die nächsten Tage erstmal beobachten. Mal sehen, was sich ergibt. Das Runterschalten auf Halbduplex und 10MBit lasse ich auch aktiv, weil ich den Pi sowieso nicht mit 100MBit erreichen kann. Allerdings wäre es schön, wenn ich die dafür nötigen Parameter in die Netzwerkkonfiguration eintragen könnte, dann kann ich den Aufruf von mii-tool sparen. Weiß jemand, ob und wie das geht?

  • Manchmal geht es schneller, als man glaubt!

    Ich glaube, ich kann etwas zur Aufklärung des Mysteriums beitragen:

    Eben fiel mein Blick auf den Pi, und ich sah an den LED, daß das Netzwerk wieder mit Vollduplex und 100MB unterwegs war, obwohl ich es manuell auf 10MB/HalbDuplex gestellt hatte. Kurz nachdem ich das gesehen hatte, meldete sich der Pi auch bereits nicht mehr.

    Dann habe ich ein paar Minuten gewartet, bis mein Cronjob anschlug, und sie da: jetzt ist der Pi wieder erreichbar!

    Und im Log steht:

    Code
    Mi 2. Apr 17:15:01 CEST 2014 Netzwerk in Ordnung
    Mi 2. Apr 17:20:04 CEST 2014 Starte Netzwerk neu

    Und jetzt sind auch wieder die Lampen für Vollduplex und 100MB aus.

    Ich würde mal sagen, damit habe ich den Übeltäter. Jetzt brauche ich nur noch sein Motiv.

    Im Syslog steht für die betreffende Zeit:

    Ich habe jetzt das Paket ifplugd rausgeschmissen. Mal sehen, ob es was bringt.

    Einmal editiert, zuletzt von PInguin (2. April 2014 um 17:34)

  • Hallo Zentris,

    da siehst Du, dass die noch zu identifizierende Ursache Quelle vieler ähnlicher Symptome ist.

    Hofffentlich finden wir da mal etwas Befriedigendes.


    Beste Grüße

    Andreas

    Hallo Pinguin,

    ich schließe mich der Auffassung von Zentris an. Die Vergabe einer festen IP-Adresse verhindert die permanente Erreichbarkeit nicht. Da spreche ich aus eigener Erfahrung ...


    Beste Grüße

    Andreas

    Hallo Zentris,


    [quote]
    Deine Idee mit dem regelmäßigen Netzwerkstart ist nicht die schlechteste... u.U. wird aber gerade im falschen Moment eine laufende Verbindung unterbrochen... muss man wollen..
    Besser wäre vermutlich, einfach ein periodisches Ping auf eine bekannte IP (Router z.B.), wenn keine Antwort, dann Netzwerk-restart...
    /quote]

    Genau das macht mein Program: Es pingt den Router an - wenn der nicht erreichbar ist, dann gibt's ein

    Code
    eche "nameserver 192.168.x.y" | sudo tee -a /etc/resolv.conf

    Und es pingt den Raspberry Pi selber an - wenn der nicht erreichbar ist, dann gibt's ein

    Code
    sudo dhclient eth0

    Und schon funktioniert's wieder... Aber ich würde trotzdem gern noch verstehen, welcher Automatismus die IP-Adresse des Raspberry Pi entfernt - und seltener die IP-Adresse des Routers verlorengeht.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (2. April 2014 um 20:31)


  • ich schließe mich der Auffassung von Zentris an. Die Vergabe einer festen IP-Adresse verhindert die permanente Erreichbarkeit nicht. Da spreche ich aus eigener Erfahrung ...


    Da hast Du vollkommen Recht. Ich brauche aber die feste IP wegen der Portweiterleitung auf dem Router.

    Aber immerhin verkleinert sich der Kreis der Verdächtigen: es scheint wohl an der Netzwerkkarte zu liegen. Denn ich habe seit Tagen kein Gerät am USB-Port, und trotzdem schwieg mich der Pi vorhin an.

    Hm, ich lese gerade in diesem Beitrag

    https://www.forum-raspberrypi.de/Thread-raspbia…=36552#pid36552

    diesen Satz:

    Zitat

    Workaround for a kernel bug which hangs the Raspberry Pi under heavy network/disk loads

    Kann es sein, daß dieses Problem schon längst in der Minimal-Distri erkannt und behoben wurde???

    Ich glaube, ich bin schon wieder einen Schritt weiter:

    Ich deinstalliere gerade viele Pakete, die ich gar nicht benötige, wie z.B. lxde, openbox, wolfram. Ich glaube, das könnte man durchaus als "heavy network/disk loads" bezeichnen. Dabei ist der Pi mehrmals angehalten bzw hat nicht mehr reagiert, und zwar jedesmal so lange nicht, bis die nächste Ausführung meines Cronjobs fällig war, also das Netzwerk neu gestartet wurde. Danach ging es jedesmal weiter, als sei nichts geschehen.

    Und noch etwas ist dabei sehr merkwürdig: jedesmal, wenn der Pi stockte, brannten sämliche LED, d.h. das Netzwerk hat jedesmal von alleine(!) auf Vollduplex und 100MBit umgeschaltet. Wie kann das passieren? Ich versuche gerade, herauszufinden, welcher Prozess dafür verantwortlich ist.

    Einmal editiert, zuletzt von PInguin (2. April 2014 um 22:14)

  • Hallo Pinguin,

    unter "Heavy Network loads" verstehe ich eigentlich etwas anderes.


    Zitat

    Zitat:
    Workaround for a kernel bug which hangs the Raspberry Pi under heavy network/disk loads

    Ich persönlich bemerke dieses Mysterium nur, wenn ich im Internet unterwegs bin. Dann sind in der Regel 3 bis 4 Seiten geöffnet.

    Mein Raspberry Pi greift weder auf irgendwelche anderen Netzwerk-Ressourcen zu, noch finden irgendwelche Laufwerks-Operationen durch andere Anwendungen statt. Schlimmer noch: Das Mysterium ist nicht reproduzierbar. Es passiert einfach so mal.

    Was mich auch wundert: USB-seitig sürzt irgendwas ab und zieht das LAN mit herunter - ein Dämon berappelt die USB-Seite wieder, eine LAN-seitige Aktion zur Wiederherstellung bleibt aus (die von meinem Programm dann nachgeholt wird).

    Je mehr ich drüber nachdenke, das Mysterium ist für mich ein Bug im Betriebssystem im Umgang mit dem LAN/USB-Chip LAN9512.

    Sich mit eigenen Tools zu behelfen, ist ganz nett - aber schöner wäre es, auf Betriebssystem-Ebene eine Lösung zu haben.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (3. April 2014 um 00:22)


  • unter "Heavy Network loads" verstehe ich eigentlich etwas anderes.

    Naja, alles ist relativ. Für den kleinen Pi könnte schon ein "apt-get upgrade" schwerer Netzverkehr bedeuten.

    Zitat

    Ich persönlich bemerke dieses Mysterium nur wenn ich im Internet unterwegs bin. Dann sind in der Regel 3 bis 4 Seiten geöffnet.

    Mein Raspberry Pi greift weder auf irgendwelche anderen Netzwerk-Ressourcen zu noch finden irgendwelche Laufwerks-Operationen durch andere Anwendungen statt. Schlimmer noch: Das Mysterium ist nicht reproduzierbar. Es passiert einfach so mal.

    Also bei mir läuft zumindest noch "nptd", um die Zeit korrekt zu halten und "ddclient", der regelmäßig den DynDNS aktualisiert. Ok, das ist alles kein richtig schwerer Netzverkehr, ich weiß, ich wollte auch nur Beispiele für Netzwerkzugriffe zeigen, die man schnell vergisst.

    Zitat


    Je mehr ich drüber nachdenke, das Mysterium ist für mich ein Bug im Betriebssystem im Umgang mit dem LAN/USB-Chip LAN9512.

    Ja, so sieht es aus. Und wenn ich den Satz in der Beschreibung zur Minimal-Distri richtig interpretiere. scheint er bekannt zu sein. Vielleicht sollte ich mir doch mal die neuesten Kernelquellen ziehen und den kleinen über Nacht einen Kernel backen lassen.

  • Mal so "nebenbei"
    Wenn ich einen meiner Arbeitspferd-RPs neu aufsetze, was zwar selten vorkommt, aber egal, räume ich _immer_ nach der Installation das System auf, weil ich z.B. das ganze GUI-Geraffel nicht benötige:

    Code
    # Pakete updaten, aufräumen & aktualisieren:
    sudo apt-get update; sudo apt-get upgrade
    
    
    sudo aptitude -y purge python-pygame penguinspuzzle lxappearance lxde
    
    
    sudo aptitude -y purge lxde-common lxde-core lxde-icon-theme lxinput lxmenu-data lxpanel lxpolkit lxrandr lxsession lxsession-edit lxshortcut lxtask lxterminal xinit xserver-xorg lightdm scratch midori desktop-base gnome-icon-theme gnome-themes-standard leafpad menu-xdg omxplayer xarchiver zenity pcmanfm blt dillo openbox pistore idle idle3

    Vielleicht liegt es daran, das ich damit einige potentielle Probleme beseitige (weil, die von euch gezeigten Probleme habe ich auf keinem meiner Systeme)
    Ok, die werden grundsätzlich per SSH benutzt, haben teilweise aber auch schon uptimes von 102 Tagen, ohne ein einziges Mal von Netztwerk getrennt worden zu sein (einer ist ein BC-Miner, da fällt das ja sofort auf)

    Ich habe heute mein neues Oszilloskop bekommen (und natürlich den ganzen Abend damit rumgespielt :D ) und mal die Stromaufnahme eines RPis bei Leerlauf und Teillast vermessen:
    Was ich da zu sehen bekam, hat mir etwas die Sprache verschlagen und ich beginne die Stromversorgungsprobleme unter einem anderen Blickwinkel zu sehen.
    Aber das ist ein Thema, da würde ich mal einen gesonderten Thread zur Diskussion aufmachen, weil ich da auch Bilder reinstellen will... :)

    Kurz gesagt: Die Stromaufnahme des RPs ist extrem dynamisch und schwankt um bis zu 400mA periodisch (Pulse) mit ca. 35kHz. :s

    Also: M.E. ist das Stromversorgungsproblem noch nicht von Tisch :lol:


  • Mal so "nebenbei"
    Wenn ich einen meiner Arbeitspferd-RPs neu aufsetze, was zwar selten vorkommt, aber egal, räume ich _immer_ nach der Installation das System auf, weil ich z.B. das ganze GUI-Geraffel nicht benötige:


    Das habe ich gestern auch gemacht, und dabei wieder prompt 3 mal Stillstand erlebt.

    Zitat


    Kurz gesagt: Die Stromaufnahme des RPs ist extrem dynamisch und schwankt um bis zu 400mA periodisch (Pulse) mit ca. 35kHz. :s

    Hast Du schon weitere Messungen vorgenommen? Diese Schwankungen können mehrere Ursachen haben: das schwache Steckernetzteil, welches eigentlich zum Laden von Akkus gedacht ist, dürfte mit Sicherheit einer der heißesten Kandidaten sein. Es könnte aber auch sein, daß Schreibvorgänge auf der SD-Karte viel Strom zieht. Die Netzwerk-Schnittestelle ist nach den letzten Erkenntnissen bestimmt auch beteiligt.

    Kannst Du den Link auf das andere Thema bitte hier hinschreiben, wenn Du Ergebnisse veröffentlichst?

    Einmal editiert, zuletzt von PInguin (3. April 2014 um 09:19)

  • Das gemessene NT ist das bisher stabilste, was ich für den RP in der Hand hatte !
    Die Spannung lag stabil bei 4,99V (naja, ich habe hinter dem 0,12 Ohm Shunt für die Strommessung gemessen, davor liegt also "etwas" mehr an).
    Die Ripplespannung auf der Leitung lag _nie_ über 0,1V, eher so bei 40mV, die Strompulse waren quasi nicht zu sehen. Ich war ebenfalls erstaunt und habe die Messung und den Messaufbau nochmal geprüft...

    Jo, den Link hau ich dann hier auch rein :)

  • Schon mal ein Danke für Deine Mühen!

    Ich frage mich auch gerade, ob es eine gute Wahl war, den Kernel für den Pi als "preemptive" zu übersetzten. Vielleicht ist die Hardware nicht wirklich echtzeitfähig, und das, was wir hier an Ausfällen erleben, ist die Folge davon.

    Ich werde mir noch mal die Anleitung für den Kernel durchlesen, und mir dann einen eigenen Kernel mit der Option "no forced preemption" backen. Ich habe so das Gefühl, daß der Pi damit besser laufen wird. Zumindest bei mir, als Server.

Jetzt mitmachen!

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