Ich habe ein Problem mit meinem Raspberry 4B (1 GB RAM). In unregelmäßigen Abständen (manchmal schon einige Stunden nach dem Hochfahren) reagiert der Desktop nicht mehr. Die Maus bewegt sich noch aber ich kann nichts mehr öffnen oder schließen usw. Per SSH komme ich noch auf die Konsole drauf, dann mache ich einen Reboot und dann läuft er erstmal wieder bis zum nächsten "einfrieren". Manchmal sieht die Grafik auch merkwürdig aus, die Eingabefelder und auch die Schaltflächen oben an den Fenstern sind dann teilweise schwarz eingefärbt. Ich habe ein Bild von der Anmeldemaske angehängt wie das heute aussah. Manchmal ist es aber auch so, dass mitten drin einfach die geöffneten Bash-Fenster mit den Scripten verschwinden. In dem Fall kann ich über den Desktop wieder neue Fenster öffnen und die Scripte wieder starten. Gelegentlich schien auch das Dateisystem verschwunden zu sein. Ich konnte also nicht mehr im Dateisystem navigieren und ich meine dass dann auch das gelbe Ordner-Symbol vom PCManFMDateimanager oben in der Leiste verschwunden war.
Operating System: Debian GNU/Linux 13 (trixie)
Kernel: Linux 6.18.34+rpt-rpi-v8
Die CPU-Temperatur beträgt meistens um die 40 °C.
Ich habe irgendwann XScreenSaver nachinstalliert weil ich eine automatische Bildschirmsperre haben wollte, aber die Probleme bestanden schon davor. Das Betriebssystem läuft auf einer "SanDisk Ultra 64 GB microSD XC I 10" und ich lasse zwei Python-Scripte laufen, eines loggt RS485 Nachrichten von meiner Heizungssteuerung (USB to RS232/485/TTL Adapter von Waveshare) sowie Temperaturen von ein paar DS18B20 Sensoren und das andere steuert über HTTP-Requests eine Funksteckdose. Ich hatte schon die SD-Karte im Verdacht, aber die Probleme traten ja schon ganz am Anfang auf und da konnte die neue SD-Karte unmöglich schon zu viel beschrieben worden sein. Das Netzteil ist ein Original Raspberry Pi Netzteil mit 15 Watt (5,1 V, 3,0 A, USB Type-C).
Bevor ich jetzt anfange irgendwelche Ersatzteile zu bestellen (z.B. stärkeres Netzteil oder eine High Endurance microSD Card), welche Ursache haltet ihr für wahrscheinlich?
Wenn du noch per SSH auf die Konsole kommst, würde ich zuerst mal mittels htop oder btop nach Auffälligkeiten schauen: Prozesse mit hoher CPU oder Speicherauslastung, andauernde I/O Operationen, RAM voll und Swap ausgelastet...
übertaktest du den RPI? Bei Bildfehler würde ich jetzt eher eien Hardware defekt vermuten RAM / CPU oder die Lötstellen davon. Hast du einen A2 µSD-Karte, wenn das nur eine alte Class 10 Karte ist hängst du am I/O Flaschenhals fest.
mit sudo iotop -o kannst du dir mal anschauen welche Prozesse dir die Karte totschreiben. Meist fängt es damit an das der RPI hängen bleibt weil die Speicherkarte mehrere Sekunden lang aussetzt irgendwan setzt der interne Controller die Karte dann auf read-only.
Ich habe vor ein paar Wochen eine PI4B auf einen btrfs rootpartition aufgesetzt, da das 5V Meanwell Netzteil, etwas Probleme hatte, wenn die Netzspannung bei Abschalter einen größeren Last (18kW) etwas hochging, dabei hat es mir anscheinend bei diesem kleinen Ausfall auch ne Karte zerschossen. Konnte das Dateisystem wieder reparieren,habe das ganze dann aber auf btrfs aufgesetzt. Das scheint bei plötzlichen Ausfällen gutmütiger zu sein da die alten Daten erst gelöscht werden wenn der aktuelle Schreibvorgang erfolgreich war.
in der fstab kannst du die Optionen noatime und z.B. commit=120 eintragen, das verhindert das die Zeiten jedes Lesezugriffs geschrieben werden und Daten aus dem RAM werden erst nach 120 Sekunden auf die Platte geschieben, zuvor hat das immer alle paar Sekunden Zugriffe gegeben.
Die Systemlogs landen jetzt erstmal auf einen RAM Laufwerk und werden nur ein paar mal am Tage auf die SD Karte geschrieben, aber mit dem Risiko wenn was schief läuft sind die logs weg.
Dann kann man den Kernel Buffer und das swapping verhalten noch etwas einbremsen.
Bei Bildfehler würde ich jetzt eher eien Hardware defekt vermuten RAM /
CPU oder die Lötstellen davon
Könnet ein Hardware-Grafik-Fehler denn so wie auf dem Bild aussehen? Leider ist das mein erster Rapspberry, aber bei den wenigen fehlerhaften PC-Grafikkarten die ich hatte zeigten sich in solchen Fällen eher Pixelfehler oder bunte Muster oder auch flackern. In meinem Fall sind die Bereiche wo die Fehler auftreten ja ungewöhnlich sauber abgegenzt.
Meist fängt es damit an das der RPI hängen bleibt weil die Speicherkarte
mehrere Sekunden lang aussetzt irgendwan setzt der interne Controller
die Karte dann auf read-only.
Kann man dieses Verhalten (read only) irgendwie ändern? Meine Scripte werden hoffentlich nicht die Karte an ihre Grenze bringen, auch wenn die nur Class 10 hat. Die Scripte schreiben vielleicht hundert Zeichen alle paar Sekunden an das Ende einer Text-Datei. Ich hatte ja vorher etwas recherchiert und dachte eigentlich, dass ich mit meiner SanDisk Extreme nicht viel falsch mache, da die teilweise sogar empfohlen wurde und die Kritik eher in die Richtung ging, dass man die bei sehr hoher permanenter Belastung eventuell schon nach einem Jahr entsorgen muss. Eigentlich wollte ich mir langfristig ne SanDisk High Endurance zulegen, weil die angeblich langlebiger bei permanenten Schreibzugriffen sein sollen. Aber auf den Abbildungen sehe ich da weder A1 noch A2. Wenn der Raspberry bei Verzögerungen auf das Schreiben warten würde und alles andere so lange im RAM gepuffert wird, könnte ich damit leben. Kann man das voreilige Einstufen des Controllers als read only irgendwie ändern?
Btrfs klingt gut und ich werde auch versuchen Deine anderen Optimierungs-Vorschläge umzusetzen.
Ich verstehe nicht, warum bei der Ausgangslage (Pi 4 B usw.) heute noch SD-Karten eingesetzt werden. Das mache ich nur noch mit meinem Bastel-Pi. Selbst bei meinem pihole (Pi 2 B, 24/7) wird nur von SD gebootet, dann per USB von SSD gestartet. Kostet genauso viel und läuft seit Jahren problemlos. Und das ganze wegen easy Datensicherung mit LVM und snapshot, den selbst der Pi 2 B dann ganz in Ruhe Weg sichern kann.
Der Pi 4 B kann sogar schon direkt von SSD booten.
In der Tat hatte ich anfangs auch solche Probleme. Aber mit einem anderen USB-Adapter war dann Ruhe. Einfach Mal nach den magischen Adaptern suchen (lsusb, falls Du sowieso noch eine hast).
Der Pi 4 B kann sogar schon direkt von SSD booten.
Kann er nicht, da man eine SSD gar nicht direkt anschließen kann. Er kann von USB-Massenspeicher booten. Der aber kann genausogut eine Festplatte, ein simpler USB-Stick oder was auch immer sein.
Anders sieht es beim Compute Module 4 aus - das belegt nicht die eine PCIe-Lane mit einem USB3.x-Controller, sondern erlaubt es, direkt daran eine NVMe-SSD zu betreiben. Und dann kann diese Variante des Raspberry Pi 4 tatsächlich auch direkt von SSD booten.
Das alles setzt natürlich voraus, daß das Compute Module auf einer Trägerplatine steckt, die entweder einen m.2-Sockel für eine SSD oder aber einen PCIe-Slot aufweist, in den man dann mit einem m.2-PCIe-Adapter die SSD reinsteckt.
Ich kaufe inzwischen keine normalen Pis mehr, sondern nur noch Compute Modules und Waveshare Carrierboards wie dieses hier für den CM5:
https://www.waveshare.com/cm5-io-base-b.htm
Auf der Unterseite ist ein M.2 Key M Slot, wo entweder eine SSD oder irgendwas anderes reinkommt. Zudem gibts die Compute Modules auch mit EMMC statt SD. EMMCs sind quasi SD-Karten im IC-Format, die schneller sind, langlebigeres Flash und einen besseren Controllerchip enthalten.
Weiterhin denke ich, das die 1G RAM unterdimensioniert sind. Ich habe einen Arbeitskollegen mit Olimex-Boards (A20, 1GB RAM, EMMC), und der hat auch irgendwelche seltsamen Probleme, die ich bei 4G-Boards nie gesehen habe.
Du willst ja auch um jedem Preis vermeiden, dass Dein System swappen muss. Das geht ja auch Flash und kostet Schreib/Löschzylen.
Aber selbst da habe ich mich darum gekümmert die dauernden
Schreibvorgänge zu verringern.
Sofern das keine extreme Ramsch-SSD ist oder eine sehr kleine (< 32 GByte), ist es effektiv nicht drin, so etwas "totzuschreiben". Die Mühe kann man sich sparen, wie zig Desktoprechner tagtäglich beweisen, die jahrelang mit einer SSD arbeiten, auf der sich ein Windows ausmärt.
war ja kein großer extra Aufwand habe das bei einem Pi wegen der sd-Karte gemacht und der SSD schadet es sicher auch nicht Schreibvorgänge zu verringen, sind übrigends WD RED 500GB da bewirbt der Hersteller mit 1000 Terrabyte write statt 300 TB bei den (Consumer) Blue Modellen. Vermutlich fängt der interierte DRAM auch kleine Daten ab damit die nicht ständig geschrieben werden müssen bis ein ganzer Block zusammen kommt
SSDs, die unter dem Label "WD" verkauft wurden, sind von SanDisk. Und wie es bei SanDisk um die Qualität bestellt ist, haben einige zu ihrem Leidwesen herausfinden können.
Achte höllisch darauf, nach Firmwareupdates für die SSD zu suchen, und die auch einzuspielen, sonst kannst Du sehr große Freude haben.
SanDisk ist WD.
Das ist so wie Parkside. Das ist auch Lidl. Aber Lidl hört sich auf nem Gartenhäcksler doof an.
WD hat sich nur überlegt, das man mechanische und elektronische Datenträger namentlich trennen sollte und verkauft daher drehende Scheiben unter dem Namen WD, SSDs dafür als SanDisk. Weil "dem Namen vertraut man bei Speicherkarten mehr als uns".
Und WD hat irgendwo stehen, das sie überhaupt niemals gar keine Updates raushauen, für keins der Laufwerke.
Da kann man sich jetzt seinen Teil zu denken...
Oder hat sich das in diesem Jahr schon wieder geändert???
SSDs, die unter dem Label "WD" verkauft wurden, sind von SanDisk. Und
wie es bei SanDisk um die Qualität bestellt ist, haben einige zu ihrem
Leidwesen herausfinden können.
Sandisk hatte früher ein Joint-Venture mit Toshiba, der Speicher kam also von einer Toshiba FAB und Sandisk beteiligte sich an den Kosten.
WD hat Sandisk übernommen inkl. der Fab-Anteile (jetzt Kioxia).
Ich bin da genauso beruhigt wie mit Speicher von Samsung, Hynix und Micron.
Und entschuldigung für das Terrabyte, das r prrellt auf meiner Tastatur so starrk ;-)
Könnte es sein, daß die Scripte Tochterprozesse starten oder selbst eine Schleife ausführen? So etwas kann dazu führen, daß sich Prozesse mit der Zeit tot rennen. So was hatte ich mal mit ein per Cron gestarteten Bashscript, das diverse Grafiken für eine Webseite aus einer RRD erstellen sollte. Ich hatte die Zeitabstände etwas zu knapp bemessen, so daß immer mehr Instanzen des Scriptes gestartet wurden, womit der Pi insgesamt immer langsamer wurde. Am Ende ist ihm die Luft ausgegangen und er ist einfach eingefroren.
Der Hinweis von Manuel die Prozesse zu überprüfen ist da schon mal ein guter Weg. Manchmal reicht da auch ein einfaches "sudo ps -A". Da einfach mal prüfen ob Prozesse mehrfach laufen, obwohl eigentlich nur eine Instanz laufen sollte.
Rein Interesse halber mal noch die Frage, warum läßt Du das Ding mit einer GUI laufen? Deine Anwendung ist ist doch prädistiniert dafür auf eine GUI zu verzichten.
Kann man dieses Verhalten (read only) irgendwie ändern? Meine Scripte
werden hoffentlich nicht die Karte an ihre Grenze bringen, auch wenn die
nur Class 10 hat.
Meine Pi's haben alle nur Class 10 Karten und laufen seit vielen Jahren fast störungsfrei. Allerdings schreibt keiner der Pi's auf die SD. Schreiboperationen erfolgen ausschließlich auf ein NAS-Laufwerk im Netz. Dem Pi (BananaPi) der als Empfänger für Wettersatelliten dient habe ich eine SSD spendiert, der braucht die SD nur zum Booten.
Das Problem sitzt in solchen Fällen meist vor dem Pi, diese Erfahrung mußte ich selbst schon machen. Fehler in Scripten sorgen oftmals dafür das sich das Ding am Ende tot rennt. Schreiben auf SD's ist bei Pi oftmals der Flaschenhals, insbesondere dann wenn so ein Schreibvorgang mal deutlich länger dauert und sich Schreibvorgänge bei per Cron gestarteten Scripten überlappen.
Selbst bei meinem pihole (Pi 2 B, 24/7) wird nur von SD gebootet, dann
per USB von SSD gestartet. Kostet genauso viel und läuft seit Jahren
problemlos.
Die 64 GB microSD-Karte hat mich weniger als 20 Euro gekostet. Bekommt man für das Geld wirklich eine vernünftige USB-SSD?
Weiterhin denke ich, das die 1G RAM unterdimensioniert sind.
Ich glaube nicht dass mein Hauptproblem (einfrieren) darauf zurückzuführen ist, aber generell hast Du sicher recht. Ich habe inzwischen Einträge im Log gefunden, die eventuell auf ein Problem mit der Hardwarebeschleunigung in der GPU unter Trixie hindeuten:
Rein Interesse halber mal noch die Frage, warum läßt Du das Ding mit
einer GUI laufen? Deine Anwendung ist ist doch prädistiniert dafür auf
eine GUI zu verzichten.
Hast ja recht, ich habe das aus Bequemlichkeit gemacht, weil ich es per VNC komfortabler finde diverse Terminal-Fenster zu verwalten, Scripte zu starten, parallel in der Entwicklungsumgebung zu arbeiten, etc. Das kann man zwar auch alles lokal Einrichten (SSH, Zertifikate, Tmux, etc.), aber ich wollte erstmal ohne großen Aufwand mit dem Raspberry starten. Ich habe das OS inzwischen aber auf Headless umgestellt.
Das eine Script loggt die RS485-Daten die von der Heizungssteuerung ca. alle 9 Sekunden kommen. Die Werte der Temperatursensoren speichere ich alle 15 Sekunden. Das werde ich später sicherlich noch optimieren, damit weniger Schreibzugriffe entstehen, aber ich ging davon aus, dass ich zumindest im Testbetrieb die paar hundert Bytes pro Log-Eintrag so speichern kann, ohne dass mir das OS ständig abschmiert. Langfristig würde ich dann ein zuverlässigeres Speichermedium verwenden.
Die Scripte schreiben vielleicht hundert Zeichen alle paar Sekunden an
das Ende einer Text-Datei.
wenn die auf dem Swap liegt, schreibst du die Karte tot und dann ist sie nur noch lesbar.
Wenn dann sollte man den Swap abschalten auf ein NAS schreiben oder RAM für eine Ramdisk für diese Swap einrichten, RAM kann zumindest nicht totgeschrieben werden.
Das SD Karten aller Arten durch Linux Swap getötet werden kenne ich seit RASPBMC auf PI1, später OSMC ab PI2 bis PI3 immer wieder, ab PI4 habe ich aufgegeben immer wieder neue Formen so daß meine gefrästen Vollalu nicht mehr passen, neue Buchsen (miniHDMI), neue Netzteile.... und dann jede Menge Anleitungen die veraltet sind weil fast nie, Linuxversion, Kernelversion und Abhängigkeiten genannt werden, jedesmal Probeinstallation, Test, Sicherung und bei Fehlfunktion, wieder alles zurück nervt auch.
Ich habe ein Problem mit meinem Raspberry 4B (1 GB RAM). In
unregelmäßigen Abständen (manchmal schon einige Stunden nach dem
Hochfahren) reagiert der Desktop nicht mehr. Die Maus bewegt sich noch
aber ich kann nichts mehr öffnen oder schließen usw. Per SSH komme ich
noch auf die Konsole drauf, dann mache ich einen Reboot und dann läuft
er erstmal wieder bis zum nächsten "einfrieren".
Mein Verdacht ist derselbe wie jener, den einige andere Menschen in diesem Thread bereits vermutet haben: die von Dir beschriebenen Symptome deuten darauf hin, daß die Ressourcen des Systems überstrapaziert werden, wobei das mehrere Ressourcen betreffen kann: Memory- oder Disk-I/O, die CPU oder die Belegung des Arbeitsspeichers.
Was mir bisher allerdings ein wenig gefehlt hat, ist eine langfristigere Betrachtung des Systemzustands. Unter den vielen verfügbaren Lösungen dafür neige ich zum traditionellen Ansatz mit dem System Activity Reporter aus dem Paket sysstat. Wenn er eingeschaltet ist liest der in periodischen Abständen die Performance-Counter des Kernels und schreibt die erhaltenen Werte in komprimierte Binärdateien in /var/log/sysstat/.
Wie oft die Werte gesammelt werden, wird in älteren Versionen von einem Cronjob und in neueren Versionen von sysstat-collect.timer konfiguriert. Wie lange die Daten bis zu ihrer automatischen Löschung vorgehalten, welche Daten in einigen Bereichen gesammelt werden sollen, wann und wie die Daten komprimiert werden sollen und Weiteres kann mit /etc/sysstat/sysstat gesteuert werden. Ob diese Sammlung nach der Installation bereits enabled ist, weiß ich nicht mehr, das kann in neueren Versionen mit "systemctl status sysstat-collect.timer" und in älteren in /etc/default/sysstat überprüft werden. Durch das komprimierte Binärformat ist der benötigte Diskspace recht überschaubar, bei mir werden die Daten für ein Jahr vorgehalten und belegen nur ca. 150 MB.
Die Daten aus den sysstat-Dateien können dann mit dem Werkzeug sar(1) tabellarisch und mit sadf(1) in den Formaten CSV, JSON und XML ausgegeben werden; ich persönlich nutze meistens das JSON-Format und füttere die Daten dann in Elastic- oder OpenSearch. Dadurch können mit deren Webfrontends Kibana und OpenSearch-Dashboards direkt hübsche Kurven gezeichnet, die Daten passend selektiert, und weitere lustige Dinge gemacht werden. Visualisierungen und Reports mit Python, Pandas und Jupyter-Lab sind auch schnell gemacht, wenn man sich mit diesen Werkzeugen ein bisschen auskennt. Ganz bestimmt gehen auch Tabellenkalkulationen, und definitiv natürlich auch jq(1) oder yq(1).
Einen relativ aktuellen Artikel zu sysstat findest Du hier [1].
Wenn Du festgestellt hast, woran es liegt, kannst Du mit den Prozeß-Accounting im Paket acct oder mit dem Audit-Daemon im Paket auditd die Ursache genauer eingrenzen, welcher Benutzer und / oder welches Programm der Übeltäter ist. Längere Ausführungen dazu möchte ich Dir aber einstweilen ersparen -- find' Du erstmal raus, ob irgendeine Ressource des Systems überlastet wird. Viel Spaß, Glück und Erfolg! :-)
Meine Raspi liefen auch alle mit SD-Karte ohne Probleme. Die einzige Änderung war das Swapfile zu deaktivieren und statt dessen eine Swap-Partition auf der SD-Karte anzulegen. Vorher hatte ich es immer wieder mal geschaftt, dass der Raspi nicht mehr von der SD-Karte booten konnte. Meistens konnte ich das mit Hilfe eines Adapters für die SD-Karte an einem Linux-Rechner mit fsck wieder reparieren.
Die einzige Änderung war das Swapfile zu deaktivieren und statt dessen
eine Swap-Partition auf der SD-Karte anzulegen.
Kannst du erklären, was das verbessern soll? Wenn die Karte abschmiert, wird sie komplett read-only, da hifd die andere Partition auch nichts oder verhindert das das das Filesystem der Rootpartition nichts abbekommt?
Kannst du erklären, was das verbessern soll?
Wenn die Karte abschmiert, wird sie komplett read-only, ...
Um das zu verstehen werden ganz klar Grundlagen benötigt. Auf die SD-Karte wird immer noch sequentiell in Blöcken geschrieben. Wenn also die SD-Karte in den RO-Mode wegen eines Fehlers in der Swap verfällt, dann war der letzte Block in den anderen Partitionen aber fertig. D.h. im worst-case Fall ist in der Regel die andere Partition noch read-only möglich zu mounten und die Dateien können kopiert werden.
Hinzu kommt noch, dass auf der Swap-Partition schon im Zeitalter der mechanischen Festplatten verteilt gespeichert und gelesen wurde.
Ich kenne mich mit Linux jetzt nicht aus, aber der Pi schreibt doch auch öfters auf die SD-Karte? Könnte die einen Lesefehler haben und geladene Programme beschädigt sein?
Das ist jedoch hier irrelevant. Wenn Zellenfehler auftreten, dann trifft es in der Regel zuerst die Zellen, die gerade der Swap-Partition zugeordnet sind. Dabei ist bei SD-Karten der vorher geschriebene Block in der Root-Partition und deren Journaleintrag gelaufen, aber die Datei vielleicht noch nicht fertig geschrieben. Und das macht halt weniger Ärger.
Bei SSD läuft mehr parallel, da auch mehr Controllerpower vorhanden ist. Somit ist das Schreiben von Blöcken in die Flash-Zellen unabhängig von der Reihenfolge, wie diese angeliefert werden. Diese haben aber auch noch Funktionen implementiert, damit im Falle einer Erschöpfung der Istzustand des Journalings und der Zellenzuordnungen greifbar ist zum Auslesen, also Datenrettung.
Prinzipiell kann einem auch der Flash-Controller der SD-Karte einen Strich durch die Rechnung machen. SD-Karten sind dafür spezifiziert, mit dem für sie vorgesehenen Dateisystem genutzt zu werden, und das kann sehr wohl bedeuten, daß der Flash-Controller diesbzezügliche Optimierungen vornimmt.
Es /muss/ nicht, aber es kann.
Und, nur um das nochmal wiederzukäuen: SD-Karten bis einschließlich 2 GiB verwenden FAT16, SD-Karten (SDHC) bis einschließlich 32 GiB vewenden FAT32, größere SD-Karten (SDXC) verwenden exFAT.
Daß zig hunderttausend Raspberries problemlos mit ext4 oder was auch immer für Dateisystemen glücklich sind, ist leider kein Beweis dafür, daß das obenstehende völlig irrelevant ist; denn es gibt auch ausreichend viele Leute, die --aus welchen Problemen auch immer-- massive Probleme mit SD-Karten in ihren Raspberries und ähnlichen Rechnern haben.
Da leider SD-Karten praktisch nie mit irgendeiner Form ernstzunehmender Spezifikation daherkommen (oft stehen nur Fantasiewerte für in der Praxis nie erreichbare Geschwindikeiten drauf), kauft man also die SD-Karte im Sack. Und Hersteller wie SanDisk (die aus irgendeinem Grund von manchen immer noch als Qualitätshersteller angesehen werden) verkaufen unter blumigen Bezeichnungen irgendwas, und nächste Woche was anderes.
Bei SSDs ist es derzeit aufgrund der vom KI-Kackscheißdreck verursachten Marktverknappung kaum noch anders, da wird irgendwelcher Müll in den Chipfertigungshallen zusammengefegt und auf irgendwelche Platinen geklatscht, um für schön viel Geld verkauft werden zu können.
Das eine Script loggt die RS485-Daten die von der Heizungssteuerung ca.
alle 9 Sekunden kommen. Die Werte der Temperatursensoren speichere ich
alle 15 Sekunden.
Das ist schon recht häufig. Temperaturen ändern sich nicht so schnell, da sind Messintervalle von 1 - 3 Minuten völlig ausreichend. Für die Heizungssteuerung sollten auch 30s ausreichend sein.
Erzeugst Du aus den Daten Grafiken? Bei mir war genau das der Flaschenhals. Da hat die Erzeugung der Grafiken länger als so ein Abfrageintervall gedauert, so das immer wieder eine neue Instanz des Scriptes durch Cron gestartet wurde, während die vorherige Instanz noch lief. Am Ende ist dem Pi einfach die Luft ausgegangen. Wenn Du Grafiken erzeugst, dann dies in ein separates Script auslagern.
Wie speicherst Du die Daten? Datenbank oder csv? Bei csv würde ich jeden Tag eine neue Datei anfangen. Wenn die Dateien groß werden, dann braucht auch dies Zeit beim Zurückschreiben auf die SD.
Meine Raspi liefen auch alle mit SD-Karte ohne Probleme. Die einzige
Änderung war das Swapfile zu deaktivieren und statt dessen eine
Swap-Partition auf der SD-Karte anzulegen.
Was meinst Du wo bei einem Pi das Swapfile liegt? Richtig, auf dem Filesystem und das ist beim Pi normalerweise auf einer SD.
Eine separate Swappartition bringt da gar nichts, wie von andern schon gerschrieben wird die SD mit der Zeit einfach tot geschrieben und ist dann nur noch ro. Das einzige was beim Pi wirklich dauerhaft hilft, ist die Schreibvorgänge auf die SD so klein wie möglich zu halten.
Deshalb ist die erste Maßnahme das Logging komplett abzuschalten. Als zweite Maßnahme empfiehlt es sich das Swapping abzuschalten, bei headless betriebenen Pi's wird das im allgemeinen nicht benötigt. Als dritte Maßnahme wäre, alle Schreibvorgänge auf eine NAS zu oder eine angeschlossene SSD zu verlagern. Bei letzterer hat sich als günsting erwiesen eine Parition für home, eine Partition für temp und eine für var anzulegen. Damit finden die Schreibvorgänge vorzugsweise auf der SSD statt. Wenn man unbedingt eine Swappartion haben möchte, dann gehört diese auch auf die SSD. Mit einer so partitionierten und angeschlossenen SSD kann man dann auch wieder das Logging einschalten.
Ich habe derzeit 5 Pi's am Laufen und seitdem ich die nach den oben genannten Punkten konfiguriert haben, laufen die. Der eine Pi tut dies seit mehr als 10 Jahren.
Und, nur um das nochmal wiederzukäuen: SD-Karten bis einschließlich 2
GiB verwenden FAT16, SD-Karten (SDHC) bis einschließlich 32 GiB vewenden
FAT32, größere SD-Karten (SDXC) verwenden exFAT.
So ist es. Dem wäre noch anzumerken, daß für die SD's auch keine Partitionierung vorgesehen ist. Man macht es beim Pi, weil die Bootpartition dort ein FAT System haben muß, der Rest ist dann ext4. Warum der nicht von ext4 booten kann erschließt sich mir nicht wirklich, denn Linux könnte das problemlos.
Selbst der Banana Pi, der einen SATA-Port hat, braucht zum Booten eine FAT-Partition auf SD.
Alle anderen bekommen unmittelbar eine Fehlermeldung bzw. einen Status
bei erfolglosen Schreibversuch.
Beim Headlesssystem siehst Du das aber in der Regel nicht sofort. Diese Systeme arbeiten ja mehr oder weniger autark. Da merkt man das nur wenn plötzlich keine Daten mehr kommen oder man sich z.B. per ssh auf dem System einloggt.
Gut man könnte sich bei Fehlern eine Mail schicken lassen, aber auch die muß man erst mal abrufen.
Warum der nicht von ext4 booten kann erschließt sich mir nicht wirklich,
denn Linux könnte das problemlos.
Der Bootloader muss es können, nicht der Kernel. Möglicherweise hat man sich für fat32 als FS für die Bootpartition entschieden, weil damit auch Windowsuser die Boot-Konfiguration leicht anpassen können: Man darf nicht vergessen, dass so’n Pi für für nicht wenige Nutzer das erste „offene“ (i.e. nicht embedded) Linux-System im Haus ist, und fat32 der kleinste gemeinsame Nenner über die verschiedenen Betriebssysteme ist.
Um mal zum Thema zurückzukommen: Gibt es denn nun schon Erkenntnisse, warum sich der Pi aufhängt? An kaputtgeschriebener Karte wird’s ja hier nicht hängen, wenn sich das Teil im Anschluss wieder starten und normal benutzen lässt. Der DRM-Fehler dürfte im Headless-Betrieb ja auch nicht relevant sein (es sei denn, er führt dazu, dass sich Teile des SoCs aufhängen).
Zu aufwendige Adressierung intern für SD-Karten.
Bei SSD würde ich Dir zustimmen.
Die physische Struktur ist in etwa dieselbe, das OS sieht nichts davon – das bekommt die logische Struktur vom Controller. Tatsächlich gibt’s seit einiger Zeit auch SD-Karten mit Wear-Leveling, sodass die Zuordnungen nicht einmal gleich bleiben, und gerade bei Swap eine gute Chance besteht, dass sich die logischen Blöcke der Swap-Partition über die physische Struktur verteilen und eben auch mal mit logischen Blöcken der anderen Partitionen in einem physischen Block landen.
Aber wie im Beitrag oben geschrieben: Das ist hier mit einiger Wahrscheinlichkeit sowieso nicht das Problem.
Was beim Swapfile ungünstiger ist, dass dieses laufend die Größe ändert. Damit werden auch die Verzeichnis-Journale stärker mit Schreibzyklen belastet. Kaputte Zellen oder auch erst mal nur Checksummenfehler wirken sich dabei ungünstiger aus.
Tatsache ist, dass ich mit der Swap-Partition auf der SD-Karte deutlich stabilere Bedingungen mit den SD-Karten auf dem Raspi habe. SD-Karten, die einmal alle win bis zwei Woche mit fsck repariert werden mußten, liefen mit separater Swap zwei Jahre problemlos.
Um mal zum Thema zurückzukommen: Gibt es denn nun schon Erkenntnisse,
warum sich der Pi aufhängt? An kaputtgeschriebener Karte wird’s ja hier
nicht hängen, wenn sich das Teil im Anschluss wieder starten und normal
benutzen lässt. Der DRM-Fehler dürfte im Headless-Betrieb ja auch nicht
relevant sein (es sei denn, er führt dazu, dass sich Teile des SoCs
aufhängen).
Die Karte scheint in Ordnung zu sein. Ich hatte die Diskussionen über den Einsatz von microSD-Karten im Raspberry aber auch so gedeutet, dass es da in bezug auf "vernünftige" Fabrikate eher um eine verringerte Restlebensdauer der Speicherkarte geht. Hat meine SanDisk Ultra microSDXC UHS‑I mit 64 GB (SDSQUNR064GGN3MA) eigentlich wear-leveling? Falls sie es hat, würde ich fast schon ausschließen, dass wegen meiner zusätzlichen paar Megabyte Schreibzugriffe pro Tag schon nach ein paar Wochen die Karte totgeschrieben sein soll.
Auf Headless habe ich erst vor ein paar Tagen umgestellt. Seit der Umstellung habe ich keine Probleme mehr. Wegen der DRM-Log-Einträge im Zeitraum der Freezes vermute ich da schon einen Zusammenhang. Das schließt aber nicht aus dass ich noch andere Probleme hatte, die durch den Headless-Betrieb ebenfalls weg sind (z.B. weil durch die weggefallene grafische Oberfläche mehr Ressourcen als vorher vorhanden sind).
Vielen Dank für die vielen Ideen und die Hilfe, ich werde heute noch das von ein_typ vorgeschlagene Paket Sysstat installieren und mir näher ansehen.
Man macht es beim Pi, weil die Bootpartition dort ein FAT System haben
muß, der Rest ist dann ext4. Warum der nicht von ext4 booten kann
erschließt sich mir nicht wirklich, denn Linux könnte das problemlos.
Das hat mit dem Aufbau des Raspberry Pi zu tun, nicht mit Linux.
Beim Booten lädt die GPU(!) von einm Massenspeicher den eigentlichen Bootloader (und noch ein paar weitere Konfigurationsdaten aus einer Datei namens config.txt).
Das macht die Firmware der GPU, und erst dann wird der eigentliche Prozessor (ARM) gestartet, um dann den Bootloader auszuführen.
Und die GPU-Firmware kann halt nur Fat-Dateisysteme lesen, egal, ob von einer SD-Karte, einem USB-Massenspeicher oder einer NVMe-SSD (wenn ein Rpi mit PCIe-Bus verwendet wird).
Die GPU-Firmware kann übrigens auch übers Netzwerk booten.
Daß zig hunderttausend Raspberries problemlos mit ext4 oder was auch
immer für Dateisystemen glücklich sind, ist leider kein Beweis dafür,
daß das obenstehende völlig irrelevant ist;
Das ist zwar kein Beweis, aus statistischer Sicht dann aber doch ein starkes Indiz.
Was Swapdateien und -Partitionen betrifft, so muß natürlich angemerkt werden, daß ein System, das dank genug Arbeitsspeichers für die laufenden Programme gar nicht swappt, natürlich auch keinen Swapspace belastet. Wann so ein System swappt, läßt sich zudem mithilfe der swappiness-Einstellung des Systemkernels, des Programms prlimit(1) und der Systembefehle mlock(2) sowie mlockall(2) recht gut einstellen.
Wenn ein System swappt, ist das in den meisten Fällen ein sehr gutes Indiz dafür, daß zu wenig Arbeitsspeicher verbaut ist und die swappiness-Einstellung des Kernels zu hoch ist. Die Standardeinstellung ist 60, dann swappt das System schon wenn der Dateisystempuffer voll ist. Meine persönliche Einstellung für Raspis ist 1 -- dann swappt das System nur, wenn es wirklich nicht mehr anders geht.
Nebenbei bemerkt ist Swappen bei einer SD-Karte besonders blöd, weil SD-Karten ziemlich langsam sind. Wer also -- warum auch immer -- swappen muß, sollte das Swapfile oder die Swappartition auf ein schnelleres Medium wie eine SSD oder noch besser eine NVMe legen.
Erzeugst Du aus den Daten Grafiken? Bei mir war genau das der
Flaschenhals. Da hat die Erzeugung der Grafiken länger als so ein
Abfrageintervall gedauert, so das immer wieder eine neue Instanz des
Scriptes durch Cron gestartet wurde, während die vorherige Instanz noch
lief. Am Ende ist dem Pi einfach die Luft ausgegangen. Wenn Du Grafiken
erzeugst, dann dies in ein separates Script auslagern.
Klugerweise sollte man Grafiken gar nicht serverseitig erzeugen, sondern erst dort, wo sie angezeigt werden. Das hat mehrere Gründe. Zunächst gewinnt man dadurch die Möglichkeit der interaktiven Darstellung, so daß der Anwender hinein- und herauszoomen kann, ohne daß der Server belastet werden muß. Weiterhin sind die zu übertragenden Datenmengen viel kleiner, was Netzwerkbandbreite spart und die Latenzen verringert. Und wenn man das Ganze mit einer netzwerkfähigen Software macht, die mehrere Clients gleichzeitig bedienen kann, bekommt man quasi umsonst ein "poor man's distributed computing", bei der die Last des Renderings auf die Clients verteilt wird, so daß der Server sich nurmehr um das Protokoll und um das Herumschaufeln der (zudem idealerweise komprimierten) Daten kümmern muß.
Wie speicherst Du die Daten? Datenbank oder csv? Bei csv würde ich jeden
Tag eine neue Datei anfangen. Wenn die Dateien groß werden, dann braucht
auch dies Zeit beim Zurückschreiben auf die SD.
In Anwendungsfällen wie dem des TO bietet es sich oft an, die Daten in einer Instanz von Elastic- oder OpenSearch zu speichern. Dafür gibt es mit Kibana und OpenSearch-Dashboards sehr leistungsfähige Webfrontends, mit denen die Daten sehr schnell gefiltert, aggregiert und visualisiert werden können. Der Wermutstropfen ist nur, daß sowohl diese Programme als auch ihre Webfrontends serverseitig deutlich mehr Speicher voraussetzen das das kleine Gigabyte des TO. Wahrscheinlich würden sie mit 2 GB leidlich laufen, ich dagegen würde mindestens auf 4 GB gehen.
Alle anderen bekommen unmittelbar eine Fehlermeldung bzw. einen Status
bei erfolglosen Schreibversuch.
Beim Headlesssystem siehst Du das aber in der Regel nicht sofort.
Also, ich schon. In dem Fall schicken mir meine Monitoring-Systeme sofort Nachrichten über SMS, NTFY.sh und E-Mail. Naja klar, man braucht natürlich ein Monitoring. Aber darauf wird man bei etwas Wichtigem doch wohl nicht verzichten? :-)
gerade headless Systeme sind dafür
gedacht, daß sie über einen größeren Zeitraum stabil und unbeaufsichtigt
laufen.
Dann sorgt man dafür, daß das System nicht swappt und auf eine externe Senke loggt, oder daß es nicht mit der SD-Karte, sondern mit einer (USB-)SSD oder einer NVMe arbeitet, und regelmäßig Backups gefertigt werden. Und wer es noch zuverlässiger haben will, der sorgt natürlich zusätzlich für Redundanz.
Bei mir hat sich der Pi schon ein paar mal wegen Firefox aufgehängt.
Dann sollte das Betriebssystem den gefräßigen Prozess rauskicken, aber sich doch nicht die Hardware aufhängen. Die tut das bei Dir vielleicht aus ganz anderen Gründen, und ehrlich, ich hab' Mitleid mit ihr.
Bei mir hat sich der Pi schon ein paar mal wegen Firefox aufgehängt.
Dann sollte das Betriebssystem den gefräßigen Prozess rauskicken, aber
sich doch nicht die Hardware aufhängen. Die tut das bei Dir vielleicht
aus ganz anderen Gründen, und ehrlich, ich hab' Mitleid mit ihr.
Das tut es auch, aber vorher swappt das System und wird dadurch sehr langsam. Das kann sich für unbedarfte Benutzer durchaus wie "aufgehängt" anfühlen.
RaspberryGrafik.png
(7,3 KB)
