Ich habe neulich wieder einmal Probleme mit meinem Raspi gehabt - oder genauer gesagt mit der darauf laufenden Influx-Installation.

Das Problem hatte ich auch schon in der Vergangenheit - plötzlich verbraucht der Prozessor 100% Rechenzeit und nichts geht mehr. Ich habe zwar, damit solche Ausfälle nicht gleich alles lahmlegen einen weiteren Pi-Hole als DNS-Server eingerichtet, über den die Adressauflösung weiter funktioniert wenn der Pi mal ausfällt.

Trotzdem ist das keine schöne Sache: der Pi kann nicht ordnungsgemäß heruntergefahren werden und damit kann das Dateisystem beschädigt werden. Mir war schon seit langem klar, dass Influx daran schuld war, ich habe aber bisher nicht die wahre Ursache finden können und konnte daher nur verschiedene Maßnahmen ausprobieren, die aber alle nicht zu einer verlässlichen Lösung führten. So habe ich unter anderem die Shard Duration extrem (auf eine Stunde) verkürzt, ichj habe die Retention Policy so geändert, dass nur noch die Daten der letzten zwei Tage aufbewahrt wurden.

Nachdem das Problem in den ersten Wochen des neuen Jahres wieder verstärkt auftrat, habe ich die Beobachtung gemacht, dass der Verbrauch an Ram korreliert mit der Anzahl und Frequenz an Daten, die in die Datenbank geschrieben werden. Daher habe ich die Hypothese gestellt, dass die eigentliche Ursache für dieses Verhalten ist, dass nicht genug RAM zur Verfügung steht.

Neulich suchte ich im Internet nochmal nach diesem Problem und dieses Mal muss ich eine etwas andere Anfrage gestellt haben, als früher: ich erhielt plötzlich tatsächlich einen sachdienlichen Hinweis: Kurz zusammengefasst: Das Problem hat seine Ursache darin, dass Influx auf 32-Bit-Systemen mit zu großen Datenbanken nicht umgehen kann und abstürzt. Nach Neustart versucht es, die Datenbank wieder aufzuräumen und steckt dann in einer Endlosschleife aus Abstürzen und Neustarts fest.

Interessanterweise gibt es dazu einen Pull-Request, der das Problem beheben würde, den aber die Macher vin Influx lange ignoriert haben. Schließlich haben sie sich zu der Aussage hinreißen lassen, dass der Fix zwar schön ist, sie sich aber auf 64-Bit-Systeme konzentrieren wollen und wer 32-Bit-Systeme einsetzt - selber schuld!

Das brachte mich auf die Idee, etwas zu versuchen, das schon seit ewigen Zeiten in meinem Zettelkasten mit der Aufschrift "Man müsste mal..." liegt: Den Raspi auf einen 64-Bit-Kernel umzustellen. Dazu existieren diverse Anleitungen (oder auch hier) im Netz, die letztlich alle darauf hinauslaufen, dass man mit einem auf Buster basierenden Raspbian alles schon hat, was gebraucht wird und man lediglich in der /boot/config.txt noch die Zeile

arm_64bit=1

ergänzen muss.

Das ergab für mich ein Problem, da mein Raspi schon ein wenig älter ist, hate ich dort noch ein stretch-basiertes System. Da es aber (von mir) eh für eine gute Idee gehalten wird, ein neueres System als Basis einzusetzen, nutzte ich den Elan, den ich in mir verspürte gleich aus und nahm die Migration auf Buster in Angriff. Auch hierfür existieren viele Anleitungen im Netz (auch hier wieder ein Beispiel für eine Alternative) - doch Vorsicht: Viele behaupten, dass man dafür die Firmware des Pi upgraden sollte - Das ist falsch! Ich habe damit beinahe meinen Pi gebrickt! Daher unbedingt das Kommando

rpi-update

weglassen! Falls man das doch tut und dann - wie ich - vor einem Pi sitzt, der keinen Laut mehr von sich gibt und kein WLan mehr kennt, dann hilft dieser Tip - also jedenfalls hat er mir dabei geholfen, dass ich wieder zu einem funktionierenden Raspi kam...

Ansonsten funktionieren diese Anleitungen jedoch hervorragend. Auch mein kleiner Raspi-Experimentalserver, der per PXE bootet und sein Dateisystem auf NFS hat wurde damit zu einer 64-Bit-Buster-Maschine.

Artikel, die hierher verlinken