Raspberry Pi nicht mehr erreichbar

  • Ich brauche bitte eure Unterstützung. Nachdem ich vor 2 Wochen das Netzteil am RasPi erneuert habe, hatte ich seitdem keine Ausfälle mehr. Bis gerade vorhin, der RasPi war nicht mehr über die Konsole zu erreichen, homebridge Geräte in Homekit alle nicht erreichbar.


    Folgende Einträge habe ich im Log ausfindig gemacht und ich vermute es liegt am eth0, also dem LAN. Was genau die logs bedeuten kann ich nicht nachvollziehen. Evtl. kann mir da jemand Hilfestellung geben?


  • Alle Log-Einträge folgen dem gleichen Muster:


    Apr 22 17:55:46 raspberrypi rngd[372]: stats: Entropy starvations: 0


    Fett markiert habe ich mal den wesentlichen Eintrag. Das ist irgendein Name mit einer Nummer dahinter. Es gibt noch andere im Log:

    avahi-daemon[344]

    dhcpcd[626]

    dbus-daemon[293]

    homebridge[350]

    fake-hwclock[103]

    systemd[1]


    Der Name sagt aus, welcher Service etwas loggt. Die Zahl dahinter ist die Prozess-ID. Jeder laufende Prozess bekommt eine solche ID und behält sie auch während seiner Laufzeit. Stoppt man den Prozess und startet ihn neu, bekommt er eine neue ID zugewiesen. Soll dir egal sein.


    Du hast also Meldungen von verschiedenen Services, wobei die Meldungen von rngd wurscht sind - das hat was mit dem Zufallsgenerator deines Systems zu tun. Wahrscheinlich ist auch die Meldung des dbus-daemon, der der Interkommunikation der Prozesse auf dem System dient, egal. Aber was weiß ich davon. Der Prozess fake-hwclock hat was mit der Uhrzeit deines Systems zu tun. Der systemd startet einen weiteren Service (udev).


    Der Prozess homebrigde warnt, dass er die Netzwerkverbindung zum Harmony Hub geschlossen hat. Dein dhcpcd schreibt was davon, dass er über eth0: keine Informationen erhalten konnte. Gehört der zu pihole? Aber auch egal.


    Es geht offenbar eine Verbindung über eth0: verloren. An eth0: hängt ein Netzwerkkabel und das führt wahrscheinlich zu einer Ethernet-Schnittstelle an einem Switch (oder an einem eingebauten Switch in einem Router). Es gibt damit drei plus zwei Elemente:

    1. eth0: an deinem Raspi
    2. Ethernet-Schnittstelle an deinem Switch
    3. Kabel, die beide verbindet

    plus

    1. Netzwerksoftware auf dem Raspi
    2. Netzwerksoftware auf dem Switch


    Wenn eines von den dreien Hardwaredingern nicht richtig funktioniert, fällt die Verbindung aus. Kabel kaputt - keine Verbindung. Nur eine Ethernetschnittstelle kaputt - keine Verbindung.


    Aber auch die Software kann Probleme machen: Paketfilter falsch konfiguriert, Switchsoftware falsch konfiguriert. Oder die Software ist schlichtweg veraltet. Mal alle Komponenten einem Update unterzogen?


    Das kannst du alles nur feststellen, wenn du dich auf deinem Raspi einloggst, sobald er kein Netz mehr hat - mit einer Tastatur und einem Monitor. Wahrscheinlich bleibt der Monitor schwarz, wenn du ihn erst dann anschließt, daher sollte er die ganze Zeit dranhängen, so hässlich das auch ist.


    Das Log oben sagt jedenfalls nicht viel aus. Dafür ist der Befehl dmesg -T besser geeignet, aber nur vor einem Reboot.

  • sschuste


    Vielen Dank mal wieder für die ausführliche Erklärung!


    Dann werd ich mich mal auf die Suche nach dem Übeltäter machen 👍


    Sehe ich es richtig, dass dieser Befehl „dmesg -T„ erst Sinn macht einzugeben, nachdem sich der RasPi wieder aufgehangen hat und bevor ich nen reboot mache?

  • Sehe ich es richtig, dass dieser Befehl „dmesg -T„ erst Sinn macht einzugeben, nachdem sich der RasPi wieder aufgehangen hat und bevor ich nen reboot mache?

    Ja, ansonsten werden die Information, die du bekommen könntest, beim Systemboot überschrieben.


    Das Log, das dmesg liefert, ist noch hässlicher als die, die man im Allgemeinen schon kennt. Dagegen liest sich ein Homebridge-Log wie das erste Kapitel von Pippi Langstrumpf. Aber es enthält eine Menge Informationen über die verwendete Hardware und du darfst gerne rätseln, was das alles zu bedeuten hat.


    Die Homebridge ab Version 1.3 erlaubt es im Gegensatz zu früheren Versionen, den Homebridge-Service an eine bestimmte Schnittstelle zu binden. Das kannst du in homebridge-config-ui-x unter Homebridge-Einstellungen einstellen oder auch direkt in config.json:


    "bridge": {
    "name": "Homebridge",
    "username": "AF:95:64:EA:1D:F8",
    "port": 51826,
    "manufacturer": "homebridge.io",
    "model": "homebridge",
    "pin": "095-77-114",
    "advertiser": "ciao",
            "bind": [
    "eth0"
    ]

    },

    Das bedeutet wahrscheinlich, dass der gleichzeitige Betrieb beider Netzwerkerkkarten (wlan0 und eth0) kein Problem mehr darstellen sollte. Ältere Homebridge-Versionen schickten mal über die eine, mal über die andere Schnittstelle Daten raus, was HomeKit irgendwie wuschig gemacht hat (jedenfalls war das meine Erfahrung). Ich will damit nur sagen, dass der gleichzeitige Betrieb des WLANs dir die Möglichkeit geben würde, dich nach dem Versagen von eth0 einzuloggen und nachzuschauen, ohne dass du einen Monitor und eine Tastatur anschließen musst.


    der Befehl ifconfig ist ebenfalls ganz nützlich - er zeigt an, welche Netzwerkkarten überhaupt aktiv sind. Ich verwende nur wlan0 und daher sieht der Output bei mir so aus:


    eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500

    ether dc:a6:32:17:c2:f6 txqueuelen 1000 (Ethernet)

    RX packets 0 bytes 0 (0.0 B)

    RX errors 0 dropped 0 overruns 0 frame 0

    TX packets 0 bytes 0 (0.0 B)

    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


    lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536

    inet 127.0.0.1 netmask 255.0.0.0

    inet6 ::1 prefixlen 128 scopeid 0x10<host>

    loop txqueuelen 1000 (Local Loopback)

    RX packets 368503774 bytes 110480440109 (102.8 GiB)

    RX errors 0 dropped 0 overruns 0 frame 0

    TX packets 368503774 bytes 110480440109 (102.8 GiB)

    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


    wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

    inet 192.168.1.22 netmask 255.255.255.0 broadcast 192.168.1.255

    inet6 fd36:84f2:e2f1:2:89d2:37e5:fdfb:de0 prefixlen 64 scopeid 0x0<global>

    inet6 fe80::edf9:d542:9ad0:bda6 prefixlen 64 scopeid 0x20<link>

    ether dc:a6:32:17:c2:f7 txqueuelen 1000 (Ethernet)

    RX packets 326121146 bytes 498456708 (475.3 MiB)

    RX errors 0 dropped 0 overruns 0 frame 0

    TX packets 311907728 bytes 918591856 (876.0 MiB)

    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


    An eth0 ist kein Kabel angeschlossen, daher wird die Netzwerkkarte zwar angezeigt, aber sie hat kein IP-Adresse.

  • Ich habe gerade den RasPi mal direkt per LAN am Router angeschlossen.


    Ich hatte gar nicht mehr auf dem Radar, dass dieser an nem Switch gehangen war. Lief so jetzt ja auch die letzten Jahre ohne Probleme.


    Nun mal schauen, ob wieder Ruhe einkehrt.....

  • Nachdem ich den RasPi direkt per LAN am Router hängen hatte, tauchte das Problem erneut nach ca. 5 Tagen auf.


    Betreibe nun den RasPi seit 6 Tagen am WLAN, bisher keinen Ausfall.


    Was mir jedoch Sorge bereitet, ist der täglich abnehmende „freie Arbeitsspeicher“. Beginnend mit anfänglich 0,30 bis 0,35 GB freiem Arbeitsspeicher nach dem reboot laut Anzeige mit config-ui, so wird jetzt nach 6 Tagen noch 0,05 GB freier Arbeitsspeicher angezeigt.


    Habe nun die Befürchtung, dass mein RasPi morgen irgendwann wieder „hängen“ bleibt.


    Habe inzwischen auch gegoogelt, könnte es mit dem Swap Speicher zusammenhängen?


    Code
    free -h
    total used free shared buff/cache available
    Mem: 926Mi 827Mi 31Mi 16Mi 66Mi 35Mi
    Swap: 99Mi 99Mi 0B
    [email protected]:~ $
  • Beginnend mit anfänglich 0,30 bis 0,35 GB freiem Arbeitsspeicher nach dem reboot laut Anzeige mit config-ui, so wird jetzt nach 6 Tagen noch 0,05 GB freier Arbeitsspeicher angezeigt.

    Hast du den RAM gekauft, um ihn nicht zu verwenden? Sieh mal hier: RE: RAM Kapazität erhöhen am Raspberry Pi mit zRAM


    Was läuft denn alles auf dem Ding? Sieht wirklich ziemlich voll aus und der Raspi lagert inzwischen RAM auf die Platte / SD-Card aus. Nicht gut. Kannst du mal ein

    ps aux


    hier ins Forum posten?

  • RAM weder gekauft noch sonst was dran rum gemacht 😜


    Es löuft nur homebridge auf dem RasPi, allerdings inzwischen mit 12 Instanzen......


    Probleme tauchten auf, seit dem homebridge Update auf 1.3x


    Hier mal die Ausgabe von ps aux:


  • Es löuft nur homebridge auf dem RasPi, allerdings inzwischen mit 12 Instanzen......

    Das sagst du so leichtfüßig... ich sehe noch einen VNC-Server, das ALSA-Sound-System, die Druckersteuerung via CUPS. Geschenkt. Das Problem scheinen mir die 12 Instanzen zu sein.


    Die Homebridge 1.3 ist bestimmt ein bisschen größer als die 1.2er-Version, und nun kratzt du an der Oberkante. Eigentlich bist du schon darüber hinaus, denn dein Raspi swappt. Das bedeutet, er verwendet seinen Swap-Bereich auf der SD-Card. Der ist dafür da, um Bereiche des RAMs dorthin auszulagern, wenn der Arbeitsspeicher voll ist. Das ist immer ein untrügliches Zeichen dafür, dass man zu wenig RAM hat und das ist ein Zustand, den man wirklich nicht will.


    Das macht die Sache jetzt sehr tricky. Abhilfe schaffen hier nur zwei Alternativen:

    • größerer Raspi. Den RAM deines Raspis kannst du nicht erweitern, weil fest verlötet.
    • weniger Homebridge-Instanzen

    Beides macht wenig Freude. Auf einen größeren Raspi umziehen ist Arbeit, weil du Instanzen hast. Hier ist dann wahrscheinlich viel manuelle Arbeit notwendig. Da ich meine 15 Plugins nur über eine Instanz mache, kann ich da nur spekulieren.


    Die Anzahl der Instanzen zu reduzieren erscheint mir da der schnellere Weg, um die Situation zu verbessern. Das bedeutet natürlich, dass du Plugins aus einer Instanz in eine andere verschiebst, was gleichbedeutend ist damit, dass du Geräte von einer Bridge auf eine andere bringst, was dazu führt, dass du Automationen und Szenen anpassen musst. Ich würde trotzdem erst einmal hier ansetzen und die Instanzen einsparen, die in keinen oder nur wenig Automationen oder Szenen auftauchen.


    Was auch helfen könnte, ist der Einsatz der neuen child bridges in Homebridge 1.3. Ich habe mich damit nur am Rande beschäftigt, als ich die neue Smartapfel-Anleitung schrieb, aber hier würden dann deine 12 Instanzen unter einer einzigen Homebridge laufen. Ich glaube, das bekommt man hin, ohne dass es einem das HomeKit-Setup zerschießt, aber es verlangt eine gewisse Konzentration auf das Thema.


    Aber auf Dauer solltest du dich überhaupt von deinen Instanzen verabschieden oder sie zumindest so weit reduzieren, wie du kannst. Am besten auf eine einzige Instanz, weil die sich besser sichern lässt. Das hilft dir eh, wenn du mal irgendwann deinen Raspi tauschen musst oder allein nur die SD-Card. Das kannst du langsam Plugin für Plugin machen, wobei du dann immer wieder Szenen und Automationen nachziehen musst. Ich weiß, das ist ätzend, sehr ätzend.

  • Vielen Dank sschuste für die Bestätigung und deine ausführliche und nachvollziehbare Diagnose.


    Ich denke, ich werde - wenn ich nun schon auf den neuen RasPi 4 umziehen werde - mir gleich die neue Logik der homebridge installieren und dann mit den child bridges arbeiten.


    Es ist dann einfach „zukunftssicherer“, als wenn ich jetzt nur jede einzelne Instanz 1:1 umziehen würde......


    sschuste


    Wenn mir hierzu noch eine Frage vergönnt sei:


    Um wenig Automationen in Homekit zu verlieren würde ich im ersten Schritt alle Instanzen stoppen und dann wie in dieser Anleitung beschrieben die Ordnerstruktur sichern und mit der Einrichtung der neuen homebridge beginnen.


    Nachdem ich die child bridges drin hab, müsste ich noch schauen, wo hier genau einzelne Dateien wie config und Co. gespeichert wurden und im besten Fall kopiere ich die gespeicherten Daten an die neue Stelle. Zumindest mit der config.json dürfte dies machbar sein.


    Dann neu starten und schauen was passiert und dann erst die alten homebridge-Instanzen aus Homekit löschen. Oder übersehe ich etwas?


    Edit:


    Denkfehler, das Ziel sollte ja sein, homebridge und neue child bridges so zu konfigurieren, dass Homekit die Änderung gar nicht mitbekommt.


    Bedeutet, ich sollte die Instanzen über hb-service mit der gleichen Bezeichnung und Ports anlegen.....


    Wobei ich mir jetzt gerade während des Schreibens nicht viel Hoffnung mache, dass dies so funktionieren wird 😂😂


    Im schlimmsten Fall muss ich halt die eine oder andere Automation wieder ergänzen oder neu einrichten 🙈

  • Um wenig Automationen in Homekit zu verlieren würde ich im ersten Schritt alle Instanzen stoppen und dann wie in dieser Anleitung beschrieben die Ordnerstruktur sichern und mit der Einrichtung der neuen homebridge beginnen.

    Da kannst du machen. Zeugs sichern ist immer die halbe Miete.


    Ich würde so vorgehen:

    • Auf deinem aktuellen Raspi zwei Instanzen einsparen, indem du die Plugins unter eine andere Instanz schiebst. Dabei solltest du die Instanzen wählen, die dir am wenigsten Ärger machen beim Nachziehen deiner Szenen und Automation. Danach hast du erst mal Ruhe und kannst die nächsten Schritte in Angriff nehmen.
    • Danach ganz kniffelig: nachdenken. Soll eine zukünftiges Setup nur auf einer einzigen Instanz laufen oder müssen es zwingend mehrere Instanzen sein? Ich betreibe viele Plugins unter einer einzigen Instanz und ich stelle zusätzlich fest: in den letzten 18 Monaten hat sich die Qualität der Plugins so stark verbessert, dass ich damit null Probleme habe. Sie stören sich nicht gegenseitig, sie stürzen so gut wie nie ab. Ich habe unvermittelte Neustarts der Homebridge nicht öfter als dreimal im Jahr (jedenfalls die, die ich bemerkt habe). Eine Instanz geht also auch, aber in deinem Fall ist es wohl besser, mehrere Instanzen zu haben, die in Zukunft als child bridges abbildest, allein schon wegen der bestehenden Automationen und Szenen in HomeKit.
    • Dann würde ich versuchen: irgendeine Instanz auf dem aktuellen Raspi probehalber zur child bridge umbauen. Dazu stoppt du die Instanz und baust die child bridge für das spezifische Plugin, wobei du der child bridge exakt die Bridge-Parameter wie der gestoppten Instanz gibst: Username, Pin und Port. Das könnte theoretisch dazu führen, dass deine Automationen und Szenen ungestört weiter laufen, zumindest würde ich das annehmen. Falls das nicht klappt, kannst du die Änderungen rückgängig machen und die gestoppte Instanz wieder starten. Aber falls das klappt, dann baust du danach Instanz um Instanz auf child bridges um.
    • Falls das tatsächlich klappt, machst du danach eine Sicherung mit dem Backup-Tool von homebridge-config-ui-x.
    • Danach erstellst du eine neue Homebridge auf einem neuen Raspi nach der Smart-Apfelanleitung, die du aber nicht mit HomeKit koppelst. Du bringst sie nur so weit zum Laufen, das du dich auf der neuen Homebridge in homebridge-config-ui-x einloggen kannst. Dort spielst du nun ein das Backup deines alten Raspi ein, am besten dann, wenn der alte Raspi ausgeschaltet ist. Wunderbarerweise wird dann homebridge-config-ui-x automatisch alle Plugins installieren und deine Konfiguration wiederherstellen. Wenn alles gut aussieht, startest du die neue Homebridge neu. Ich würde nun erwarten, das HomeKit den neuen Raspi problemlos als Ersatz für den alten Raspi akzeptiert und dass alle Szenen und Automationen in HomeKit einfach ganz normal weiterarbeiten.

      Ein Pfad-Problem könnte nach dem Restore auf dem neuen Raspi auftauchen. Ich weiß wie man es löst und beschreibe es daher nicht hier und heute. Wenn es zu heftige Probleme gibt, fährst du neuen Raspi einfach runter und schaltest den alten wieder ein. Dann sollte alles wieder beim alten sein.

    Ganz ehrlich? Ich habe so etwas nie gemacht. Absolutes Neuland. Aber ich glaube, das geht. Die aktuelle Smartapfel-Anleitung ist übrigens die gleiche wie die offiziell empfohlene, nur auf deutsch übersetzt.

  • Kohle_81 Kauf dir eine Pi mit mehr Ram und verbinde dein Laufwerk (SD, USB etc.) wo dein OS installiert ist mit diesem. Er sollte ganz normal wieder starten und alles läuft wie gehabt.


    Ich habe 30 Instanzen + VNC + ngrok + deconz aktuell auf einem Pi 4 mit 4GB Ram am laufen und noch 1,2 GB Ram frei.


    Der Tipp von sschuste alles in eine Instanz zu packen kann ich nicht teilen. Bin überzeugt davon das jedes Plugin in eine eigener Instanz am stabilsten ist. Gleichzeitig bist du damit auch am flexibelsten.


    Zum Thema Sichern würde ich von det das raspiBackup.sh tool nutzen um ein ganzes Backup Image vom Pi zu erstellen. Das Wahlweise z.B. direkt auf ein NAS.


    Zum Thema Childbridges kann ich dir nicht wirklich was sagen da ich weiterhin die Instanzen nutze so wie SeydX und ich damals die Idee in die Homebridge per Pull gebracht haben. Es ist soweit ich das verstanden habe nur ein anderer Name sowie ein anderer weg einzurichten.


    Ich gehe aber schwer davon aus das du dir bei der Umstellung dein HK Setup zerschießt. Du kannst es natürlich ausprobieren so wie sschuste es dir vorgeschlagen hat.



    LG

  • Nastra


    Ich hätt schon nen RasPi 4 zuhause 😜


    Meinst du mit „Laufwerk verbinden“ etwa einfach nur die SD-Karte in den neuen RasPi stecken und gut wär?

  • Jep genau das meine ich. Wüsste nicht warum es dann nicht mehr funktionieren sollte.

  • Nastra


    Vielen Dank für den Tipp!!!


    Karte in RasPi 4 eingelegt und läuft erst mal alles einwandfrei 👍👍



    Ich hatte irgendwie ein Brett vor dem Kopf bzw. dachte ich, ich müsste es wie beim letzten Mal machen wie beim homebridge umziehen. Aber da bin ich natürlich von Debian auf Buster umgezogen, deshalb war ein Neuaufsetzen notwendig 😄😄

  • Karte in RasPi 4 eingelegt und läuft erst mal alles einwandfrei

    LOL :thumbup:

  • Ich bin jetzt aufgrund wochenlanger Abstürze immer noch skeptisch, ob die Ursache nun behoben ist. Seit heute Nachmittag bei anfänglich freiem Arbeitsspeicher mit 3,24 GB sind jetzt 5 Stunden später nur noch 3 GB frei....


    Wenn dies so weiter ginge ist ein Absturz ja auch wieder vorprogrammiert....


    Oder wie verhält sich euer RasPi bzgl. des Arbeitsspeichers?

  • Wenn dies so weiter ginge ist ein Absturz ja auch wieder vorprogrammiert....

    Da mach dir mal keine Sorge, weil das OS bei Gelegenheit aufräumt und wieder Speicher frei gibt.

    Wenn du dich beruhigen will kannst du das ja mit einem Skript einmal nachts machen ( cronjob)


    Code
    sudo sh -c "echo 1 > /proc/sys/vm/drop_caches"

    wie gesagt ... entspann dich ... :-)


    hier mal 7 Tage Speicher CPU Last und Temp .. aus meinem Grafna


    da kannst du schön sehen, wie das OS "aufräumt"

    //.ichael

    -----------------------------------


  • Seit heute Nachmittag bei anfänglich freiem Arbeitsspeicher mit 3,24 GB sind jetzt 5 Stunden später nur noch 3 GB frei....

    Das muss so und ist gut so. Der Raspi lagert nun ein paar Sachen in den RAM, weil der RAM ja viel schneller arbeitet und weil der Raspi ja jetzt genug davon hat. Eine richtige Anzeige kann dir nur free -mt geben.

    Code
    total used free shared buff/cache available
    Mem: 3828 880 188 184 2759 2869

    RAM insgesamt: 3,828 GB

    Davon für Programme benötigt: 0,880 GB

    Davon für Cache verwendet: 2,759 GB

    Völlig unbenutzt: 0,188 GB


    Verfügbar: 2,869 GB. Der Raspi lädt gern Teile des SD-Card in den RAM (buff/cache), die er wieder freigibt, falls der Platz für etwas anderes gebraucht werden sollte. Die Zahlen sind eine Ungefähr-Angabe und zeigen, wieviel RAM der User zur Verfügung hat. Was an die 4GB fehlt, hat sich das Betriebssystem geschnappt und kann gar nicht verwendet werden.


    Auf Dauer versucht der Raspi immer so viel RAM zu verwenden wie möglich. Wichtig ist für dich die Anzeige ganz rechts: available. Die meisten Programme zeigen aber lieber den irreführenden Wert free an.


    Ich räume meinen Speicher nicht manuell auf. Meine Mutter hat mich nicht unter Schmerzen geboren, damit ich Aufgaben erledige, die ein Computer auch selber machen kann.