Worauf man bei einem Raspberry Pi im Langzeitbetrieb achten sollte

 (dzombak.com)
1 Punkte von GN⁺ 2024-02-18 | 1 Kommentare | Auf WhatsApp teilen
  • Um einen Raspberry Pi über Wochen bis Jahre ohne Eingriffe zu betreiben, sollte man vorab Wiederherstellungspfade für den Fehlerfall entwerfen, damit er sich automatisch erholen kann
  • Der Leitfaden ist Teil einer breiter angelegten Zuverlässigkeitsserie, die den bisherigen Artikel zum Reduzieren des SD-Karten-Verschleißes ersetzt und Reaktionen auf verschiedene Problemtypen sowie Monitoring-Tipps bündelt
  • Die wichtigsten Risiken sind fehlgeschlagene WiFi-Verbindungen, Dienstausfälle, Abstürze durch Instabilität bei Hardware, Firmware oder Treibern sowie SD-Karten-Verschleiß oder vollgelaufener Speicher
  • Probleme mit SD-Karten lassen sich durch die Wahl einer geeigneten microSD-Karte, den Verzicht auf swap, weniger Schreibvorgänge, ein schreibgeschütztes Root-Dateisystem und bei Bedarf durch fsck abmildern
  • Das Deaktivieren von Journaling kann zwar den Verschleiß verringern, erhöht bei Abstürzen oder Stromausfällen aber das Risiko von Dateisystemschäden und passt daher nicht zu dem Ziel langfristiger Stabilität

Kritische Fehlerpunkte im Langzeitbetrieb

  • Wer einen Raspberry Pi langfristig online halten will, sollte für jede Störung durchdenken, wie sich der Pi davon erholen soll, und dabei Vorteile und Risiken möglicher Lösungen gegeneinander abwägen
  • Der Autor nutzt Raspberry Pis zu Hause unter anderem als stromsparende FM-Sender und als USV-Energiemonitore
  • Die Serie Raspberry Pi Reliability fasst selbst erlebte Problemtypen und Lösungswege zusammen und enthält auch Monitoring-Tipps, vor allem mit Uptime Kuma
  • Die Serie versteht sich als umfassenderer Leitfaden als der bisherige Artikel zum Reduzieren des SD-Karten-Verschleißes; die verlinkten Beiträge dienen als aktualisierte Nachfolger

Maßnahmen nach Problemtyp und was man vermeiden sollte

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-02-18
Hacker-News-Kommentare

  • Stattdessen habe ich angefangen, Lenovo Mini-PCs zu kaufen; mit 18 cm x 18 cm x 3 cm sind sie immer noch sehr klein.
    Heutzutage bekommt man sie sehr günstig, und sie haben ein ordentliches Gehäuse sowie Kühlung: https://psref.lenovo.com/syspool/Sys/PDF/ThinkCentre/ThinkCe...
    Direkt neben mir läuft einer mit i5-8500T, 32 GB RAM und 2 SSDs; im Idle liegt er mit automatischem powertop-Tuning derzeit bei 5 W: https://wiki.archlinux.org/title/powertop

    • Kein GPIO, I2C oder SPI. Wenn man einfach einen kleinen, leichten Server sucht, passt das, aber der Raspberry Pi ist auch wegen seiner I/O-Funktionen beliebt, die bei Consumer-/Office-Geräten selten sind.
      Man könnte eine serielle Verbindung zu einem Mikrocontroller hinzufügen, aber damit wird die Lösung weniger sauber.
    • Letztes Jahr habe ich meinen Kodi-Mediaplayer von einem RasPi 4 auf einen N3350 Mini-PC umgezogen und es nicht bereut.
      In letzter Zeit habe ich auch mein NAS (N5105) und meine Service-Maschine (3215U) auf gebrauchte Mini-PCs und entsperrte Chromebooks verlagert, die ich bei eBay oder auf Flohmärkten gefunden habe. Sie sind billig, halten den Stromverbrauch niedrig, und die Rechenleistung ist im Vergleich zum Pi eine völlig andere Liga.
    • Ich mache es genauso, verwende aber einen Dell 7060.
      In Australien kommen nach Ablauf von Leasingverträgen Tausende davon auf den Markt. Die 8500T- oder 8700T-Chips sind hervorragend, können offiziell Windows 11 ausführen und haben Hardware-Transcoding integriert, was sie gut als Plex-Server macht.
      Einen von meinen habe ich auf 2 TB SSDs und 64 GB RAM aufgerüstet, und er läuft problemlos 24/7.
    • Bei mir genauso. Ich habe einen refurbished Dell gekauft, und seitdem ist es viel weniger lästig.
      Die SD-Karte war wahrscheinlich die größte Fehlerquelle, und wenn man die Kosten für etwas wie eine SSD am RPi mit einrechnet, war es nicht mehr kosteneffizient.
    • Im Vergleich zu ARM-Hardware ist es außerdem schön, dass man praktisch jede Linux-Distribution darauf laufen lassen kann.

  • Der erste Rat sollte nicht sein, den Journaling-Modus des Dateisystems einzuschalten.
    Der erste Rat sollte sein, das Dateisystem schreibgeschützt einzuhängen, /var im Speicher zu mounten und alle Logs nicht auf den RPi zu schreiben, sondern an einen ordentlichen Node mit richtiger USV und laufendem NUT zu schicken. Wenn das Dateisystem read-only oder temporär ist, werden Stromausfälle praktisch harmlos.
    Für einen einzelnen RPi mag das übertrieben sein, aber der Autor sagte, er nutze mehrere davon im ganzen Haus.
    Außerdem ist es sinnvoll, A/B-Systempartitionen zu haben und Upgrades durch Neuschreiben einer ganzen Partition durchzuführen, danach die aktive Partition umzuschalten. Dann bleibt immer eine funktionierende Systempartition übrig, selbst wenn die neue Version einen fatalen Bug hat, und die Wiederherstellung ist einfacher.
    Auf diese Weise habe ich seit über 20 Jahren mehrere kleine/Single-Board-PCs zuverlässig in verschiedenen Rollen betrieben.

    • Der Autor hat ein paar Zeilen weiter unten einen Link zu einem Tipp für eine schreibgeschützte Konfiguration gesetzt.
      https://www.dzombak.com/blog/2021/11/Reducing-SD-Card-Wear-o...
    • Nicht nur für /var, sondern auch für Orte wie /tmp sollte man tmpfs verwenden. Das dürfte die Lebensdauer der SD-Karte deutlich verlängern.
    • Wenn man A/B-Systempartitionen hat und Upgrades durch Neuschreiben ganzer Partitionen macht, würde mich interessieren, wie der Upgrade-Prozess aussieht.
      Mich würde interessieren, wie das neue Disk-Image erstellt wird und ob man sich auf jedem Gerät einloggt und es aktualisiert oder ob es dafür Automatisierung gibt.
    • Wenn man das Dateisystem schreibgeschützt einhängt, wie macht man dann Systemupdates oder installiert neue Software?
    • Wenn man etwas wie Docker verwendet, kann ein im Speicher gemountetes /var den Gerätespeicher überschreiten.
      Möglicherweise muss man /var/lib/docker auf einen zusätzlichen Speicher verschieben.

  • 2011 habe ich einmal ein kommerzielles Produkt gebaut, das auf einem frühen Plug-Computer von Global Scale Technologies lief.
    Wir haben nur etwa 20 Stück verkauft, aber alle kamen wegen beschädigter SD-Karten zurück, und ich musste das Root-Dateisystem eilig auf read-only umstellen. Seitdem mag ich diesen Ansatz.
    Dieses frühe kommerzielle Produkt war ein Heimsicherheitsprodukt mit sehr kleinen Home-Automation-Funktionen; 2021 habe ich es unter neuem Namen als Open Source veröffentlicht, und inzwischen läuft es auf Single-Board-Computern der Jetson-Reihe: https://github.com/hcfman/sbts-install
    Inzwischen sind auch fortgeschrittene YOLO-Modelle als Trigger enthalten. Da es als Standalone-Produkt gedacht war, unterstützte es HTTPS und hatte auch eine GUI, die die gesamte Zertifikatsarbeit kapselte. Diese Funktion ist auch in der Open-Source-Version erhalten geblieben, sodass es einfach ist, selbstsignierte Zertifikate für REST-Aufrufe zwischen Geräten zu verwenden.
    Außerdem habe ich den Ansatz mit Multi-Partition-Memory-overlayFS beibehalten und erweitert; der Installer installiert zuerst ein sbts-base-System, damit andere es als ihr eigenes Basissystem verwenden können.

    • Ich habe Ähnliches erlebt. Ich habe einen 5-Dollar-Pentium-2-PC zu einer lüfterlosen, geräuschlosen Workstation umgebaut und dabei die HDD durch eine CF-Karte ersetzt.
      Mit der Zeit begann das System bei jedem Schreibzugriff auf die Festplatte für 1–2 Sekunden zu hängen, was ziemlich schmerzhaft war.

  • Menschen, die so etwas vorhaben, würde ich zuerst empfehlen zu prüfen, ob sich die benötigte Aufgabe nicht mit einem kleinen Board wie einem ESP32 erledigen lässt.
    Der Stromverbrauch ist viel niedriger, der Preis liegt bei ein paar Dollar, und für viele Einsatzzwecke reicht es völlig aus. Wer Python bevorzugt: Viele Boards unterstützen sowohl MicroPython als auch CircuitPython.
    Es lohnt sich, das anzuschauen, weil man sowohl die anfänglichen Anschaffungskosten als auch die laufenden Stromkosten senken kann.

    • Ich verstehe den Einwand, dass Embedded-Programmierung Zeit kostet und komplexer ist, aber für Hobby-Anwender halte ich es zumindest für eine hervorragende Empfehlung, die man in Betracht ziehen sollte.
      Projekte, die ich mit Mikrocontrollern umgesetzt habe, waren über Zeiträume von Jahrzehnten deutlich stabiler als Pi-basierte Projekte, und man muss sich auch weniger Sorgen machen, Teil eines Botnetzes zu werden, weil man vergessen hat, die Standard-SSH-Einstellungen zu ändern. Ich meine, der Standard war doch pi:raspberry.
      Neben MicroPython wird auch die Unterstützung für no_std Rust auf dem ESP32C3 von Monat zu Monat besser. Für jemanden, der zum Spaß kleine Heimautomatisierungsprojekte baut, können die zusätzlichen Einschränkungen das Ganze sogar interessanter und lohnender machen.
      Allerdings ist ein Pi für jemanden, der bereits mit Linux vertraut ist, meistens deutlich einfacher, und meiner Erfahrung nach sind die Kosten mindestens etwa um den Faktor 10 höher. Zusätzliche Konfigurationen wie SSD-Boot, Netzwerk-Boot, ein schreibgeschütztes Root-Dateisystem und Watchdog-Einstellungen, um dieselbe Zuverlässigkeit zu erreichen, sowie der höhere Stromverbrauch – besonders beim Pi 5 – sollten ebenfalls in die Entscheidung einfließen.
    • Kann man auf einem ESP32 einen Medienserver betreiben? Nein.
      Kann man auf einem ESP32 einen Passwortmanager-Server betreiben? Nein. Pi-hole? Geht nicht. Unifi-Controller? Geht nicht.
      Solche Empfehlungen wirken, als würden die Leute sich vorstellen, man setze einen Pi für Dinge wie einen Garagentor-Controller ein; reflexartig einen ESP32 als Pi-Ersatz vorzuschlagen, ist da nicht besonders hilfreich.
    • ESP32 und verwandte Boards sind ziemlich cool, erfordern aber eine völlig andere Denkweise.
      Wenn etwas nicht funktioniert, kann man nicht einfach HDMI und Tastatur anschließen und spontan in einer Mainline-Linux-Umgebung debuggen, in der alle üblichen Utilities vorhanden sind.
    • Ein Pi Zero verursacht Stromkosten von etwa 1 Dollar pro Jahr.
    • In einer etwas komplexeren aktuellen Konfiguration nutze ich einen Pi Zero zusammen mit mehreren ESP8266/32, die über HTTP und WLAN kommunizieren.
      Ich habe zum ersten Mal MicroPython statt Arduino verwendet und bin wirklich angetan; überraschenderweise ist es sehr stabil. Früher gingen Projekte langfristig oft wegen der WLAN-Energiezustände kaputt, aber bisher habe ich mit der MicroPython-Struktur keine Probleme.

  • „Periodisch prüfen, ob die WLAN-Verbindung in Ordnung ist, und andernfalls das WLAN-Interface oder den ganzen Pi neu starten“ läuft meistens darauf hinaus – das ist kein Hack, sondern Best Practice.
    So wie wichtige Server im Rechenzentrum eine Out-of-Band-Verbindung wie IPMI oder eine fernsteuerbare RPDU-Steckdose haben sollten, sollten wichtige Server an schwer zugänglichen Remote-Standorten Watchdog-Skripte haben.
    Natürlich muss man das je nach Einsatzzweck anpassen und die Auswirkungen eines Neustarts sowie die Ausfallzeit bis zum Neustart berücksichtigen; zumindest kann man auffällige Ereignisse protokollieren, um sie später untersuchen zu können.
    Als ich einen Remote-RPi ausgerollt habe, war eines der ersten Dinge ein einfaches Bash-Watchdog-Skript. Es war nicht nur für WLAN-Probleme gedacht, sondern für Dutzende Situationen, die kaputtgehen und sich durch einen Neustart beheben lassen können.

    • In den meisten heutigen Distributionen übernimmt diese Watchdog-Rolle init/PID 1, also systemd.
      Wenn man init nicht zutraut, Dienste zu verwalten, stellt sich die Frage, woher überhaupt die Garantie kommen soll, dass das System Dienste bereitstellt.
      Man könnte das mit Skripten nachbauen, aber über diese Phase sind wir bereits hinaus. Ich erwähne systemd oft, will es aber nicht bevorzugen; es gibt auch Alternativen.
      Die meisten Dienste nutzen die Umgebung, in der sie laufen, nicht richtig aus. Es wirkt, als erwarte man standortspezifische Anpassungen, etwa dass ein Webserver deklariert, dass er einen bestimmten Mount benötigt.
      Eine häufig übersehene Direktive ist PartOf=. Damit kann man den Neustart eines Dienstes oder einer Ressource an einen anderen koppeln.
      Noch einfacher dürfte NetworkManager eine Möglichkeit bieten, WLAN-/Portal-Prüfungen anzupassen. Man muss vielleicht nicht gleich ganz radikal werden.
    • Ähnlich überwache ich mit einem ESP8266 den WLAN-Router und das Kabelmodem. Wenn es ein Problem gibt, wird neu gestartet.
      Beim Router versucht er, sich mit der passenden SSID zu verbinden, und pingt dann den Router an; wenn eines von beidem fehlschlägt, schaltet er auf einen anderen Router um. Es gibt zwei identisch konfigurierte Router, deren Stromversorgung an den NO/NC-Kontakten eines SPDT-Relais hängt; wenn einer ausfällt, wird nur der Relaiszustand geändert und auf den anderen umgeschaltet.
      Wenn der Router lebt, ruft der Watchdog die Statusseite des Kabelmodems auf und pingt eine von drei IPs im ISP-Netz an, die offenbar der CMTS oder Geräte in deren Nähe sind, um zu prüfen, ob die HFC-Infrastruktur läuft. Wenn es sich um einen Ausfall handelt, der sich durch Neustart nicht beheben lässt, möchte ich schließlich nicht unnötig neu starten.
      Leider habe ich keine Möglichkeit gefunden, zwei Kabelmodems mit derselben MAC zu betreiben und umzuschalten, und der ISP erlaubt auch keine zwei Modems auf demselben Konto. Wenn also das Kabelmodem ausfällt, bleibt nur Neustart und hoffen.
      Daran hängt ein Batterie-Rack, das Router und Modem auch bei Stromausfall über 30 Stunden betreiben kann; seit ich es im Mai 2020 gebaut habe, war es fast durchgehend online. Der Code ist schrecklich, aber in der Praxis funktioniert es sehr robust.
    • Stimme völlig zu. Watchdog-Timer sind für Mikrocontroller und Computer, die Software „für immer“ ausführen, unverzichtbar.
      Es passieren Dinge, die sich selbst mit perfektem Code und Design nicht verhindern lassen, und Watchdog-Timer unterbrechen Endlosschleifen und setzen das System zurück. Dazu gehören Dinge wie Bitflips durch Weltraumstrahlung oder kurze Spannungseinbrüche; bei Raspberry Pi muss man sich außerdem um SD-Karten-Korruption sorgen.
      Soweit ich weiß, hat der Raspberry Pi einen eingebauten Hardware-Watchdog-Timer. Arduino hat definitiv einen.
    • Es ist Best Practice und zugleich ein Hack. Es sollte nicht nötig sein, aber weil Bugs existieren, wird es nötig.

  • Wir betreiben seit fast zehn Jahren Tausende Pis in Produktionsumgebungen und beginnen nun, auf x86 umzusteigen.
    Das Preis-Leistungs-Verhältnis des Pi ist nicht mehr das, was es einmal war. Diese Erfahrungen habe ich kürzlich auf der State of Open Con vorgestellt: https://youtu.be/vX-qK9mxKZI

    • Als CEO-Kollege im Bereich Digital Signage mit Raspberry Pi war ich überrascht, dass im Vortrag die seit dem Pi 4 mögliche Unterstützung für Secure Boot nicht erwähnt wurde.
      Unser Service nutzt sie noch nicht, aber laut Dokumentation wirkt sie ziemlich solide und kann Daten auf Disk/SD schützen.
      Wir sind mit dem Pi noch ziemlich zufrieden, und auch der Wechsel zu den offeneren APIs Mesa/DRM/KMS/FFmpeg sieht sehr vielversprechend aus, da er erst jetzt wirklich brauchbar wird.
      Da der Haupteinsatz weiterhin Digital Signage ist, spielt rohe Rechenleistung keine große Rolle. Video-Decoding, das einen großen Teil der Kosten ausmacht, wird natürlich beschleunigt, und die Abwärtskompatibilität, die mit dem Pi möglich ist, ist hervorragend. Es gibt immer noch Kunden, die seit fast zehn Jahren Pi1B+ weiterbetreiben und unsere neuesten OS-Releases nutzen.
    • Man muss die Nutzungsweise berücksichtigen. Wenn viel Leerlauf dabei ist, halte ich ARM für besser als x86.
      Auch die Lebensdauer sollte man betrachten; auch dort dürfte ARM länger halten als x86. In Sachen Modularität ist ARM ebenfalls besser als x86, weil es günstiger ist, mehrere kleine Geräte einzusetzen.
      Bei der Skalierbarkeit, also der Geschäftsfähigkeit in der aktuellen Wirtschaftslage, ist x86 jedoch besser als ARM.
      Außerdem sollten alle Graphen auf Wattbasis dargestellt werden. Dass die Leistung besser wurde, als man von 2 auf 4 ging, ist keine Neuigkeit; entscheidend ist, ob die Leistung pro Watt besser wurde.
      So betrachtet sieht man, dass die Leistungssteigerung pro Watt beim Raspberry Pi 5 nicht so groß ist wie erhofft. Es wirkt, als hätten wir in der Menschheitsgeschichte dauerhaft einen Gipfel erreicht.
      Schließlich ist zum jetzigen Zeitpunkt die einzige Hoffnung auf Fortschritt nicht bei der Leistung, sondern bei der Offenheit JH7110, wobei die 3D-Unterstützung hinterherhinkt.
    • Ich frage mich, ob es zum Ansteuern von Displays gedacht ist oder für Betriebsequipment, das GPIO nutzt, etwa Produktions- und Montageanlagen.
    • Ich frage mich, was mit dem Umstieg auf x86 konkret gemeint ist.

  • Obwohl ich nichts davon gemacht habe, liefen einige Pis jahrelang problemlos, bis sie durch neue Modelle ersetzt wurden.
    Mein HomeKit/Zigbee-Gateway und der Datenlogger sind inzwischen Pi 4. Letztlich scheinen gute SD-Karten und eine stabile Stromversorgung der Schlüssel zu sein.

    • Zustimmung. Ich habe auch mehrere Pis betrieben, und wenn etwas ausfiel, lag es an defekten SD-Karten.
      pibenchmark halte ich für eine gute Informationsquelle: https://pibenchmarks.com/
      Vor dem Kauf sollte man SD-Karten unbedingt vergleichen.
    • Ich denke, die Stichprobengröße beeinflusst die Erfahrung stärker.
      Wenn man genügend viele Geräte betreibt, geht alles schief, was schiefgehen kann, und es tauchen sogar neue Ausfallmodi auf, an die man nie gedacht hätte.
    • Bei altem Raspbian OS von etwa 2016 und früher war das Protokollieren von Zugriffszeiten aktiviert, sodass bei jedem Lesen einer Datei ein Schreibvorgang ausgelöst wurde.
      Das dürfte vermutlich der Grund gewesen sein, warum es danach so viele Berichte über beschädigte Karten gab.
    • Bei mir ist es ähnlich. Ich betreibe seit Jahren ein paar Pi3 als Cups-Server, und die Uptime wird nur bei Stromausfällen zurückgesetzt. Auch Stromausfälle sind sehr selten.
      Außer Raspbian auf eine microSD-Karte zu installieren, Cups einzurichten und USB mit dem Drucker zu verbinden, habe ich nichts gemacht. Ein weiterer verwaltet einen Netzwerkdrucker. Seitdem habe ich sie einfach laufen lassen.
    • Es ist extrem uneinheitlich. Manche hatten endlos Probleme, andere liefen lange gut. Ein klares Muster ist nicht zu erkennen.
      Inzwischen habe ich die meisten auf SSD umgestellt. Sonst fühlt es sich zu sehr wie Würfeln an.

  • Ich war überrascht, dass SD-Karten nicht als Erstes genannt wurden, und noch mehr, dass der Beitrag USB-Boot nicht vorschlägt.
    Ich habe einen Pi seit Jahren fast 24/7 eingeschaltet, und ich denke, dass es keine Probleme gab, liegt daran, dass 1) Alpine so konfiguriert ist, dass die Disk kaum angefasst wird, und 2) es keine SD-Karte gibt, die beschädigt werden kann. Warum USB zuverlässiger ist, weiß ich nicht, aber empirisch war es so.

    • Meine Argon-Raspberry-Konfiguration mit angeschlossener SSD ist ebenfalls stabil.
      Der einzige Grund für Ausfälle ist, wenn der Strom weg ist. Eine Batterie, die nur 10 Minuten überbrücken kann, wäre völlig ausreichend.
    • Mich würde interessieren, wie man Alpine so konfiguriert, dass es die Disk kaum anfasst.
      Ich möchte wissen, ob damit zum Beispiel so etwas gemeint ist: https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode
    • Ich hatte viele Pi-Karten, die mit SD problemlos liefen. Aber bei genau einer wurde die SD-Karte plötzlich extrem heiß, und es war ein neuer Pi, den ich gerade einrichtete.
      Ich habe die Karte herausgenommen und nutze diese Karte und den nächsten Pi seitdem mit USB-SSD. Das war etwas beängstigend. Trotzdem betreibe ich, wie gesagt, auch einen Pi seit Jahren problemlos als Cups-Server mit microSD.
    • Volle Zustimmung. Alle meine RPi-Ausfälle lagen an SD-Karten.
      Zwei RPis booten und laufen beide von USB und funktionieren seit Jahren gut.
    • Bei mir genauso. Ich boote per M.2 HAT von SSD, und das funktioniert sehr gut.

  • Ich betreibe seit 2017 zwei Pis fast durchgehend mit derselben SD-Karte. Stromausfälle gab es etwa zwei- bis dreimal.
    Einer ist DNS-/Print-Server, der andere läuft mit Kodi; die Medien liegen auf externem NFS. Alles, was ich getan habe, war, sämtliche Logs abzuschalten, und ich hatte nie Probleme.
    Beide verwenden SanDisk-Karten mit 2 GB. Ich erinnere mich vage, damals naiv gedacht zu haben: „wenig Speicherplatz → geringere Bit-Dichte → bessere Zuverlässigkeit“.

    • Ich nutze log2ram (github/azlux/log2ram) und bin mit dem Ergebnis zufrieden.
      Es mountet eine RAM-Disk unter /var und kopiert die Logs nur gelegentlich von der RAM-Disk auf die SD-Karte. So kann ich alle Logs ansehen, ohne die SD-Karte stark zu beanspruchen.
    • Ich betreibe Kodi auf einem Pi 1 seit fast zehn Jahren mit derselben ursprünglichen SD-Karte.
      Er ist die meiste Zeit eingeschaltet, aber manchmal schalte ich versehentlich das angeschlossene USB-Netzteil aus. Es ist ein kleines 5-Port-Netzteil, fast genauso alt, und in meinem Aufbau lässt sich der Einschaltknopf zu leicht drücken.
    • Ich habe einen RPi, der seit 2014 ohne Unterbrechung mit derselben SD-Karte läuft und eine Wetter-Website bereitstellt.
      Im Wesentlichen habe ich alle Logs und Webseiten auf tmpfs gemountet; die DB liegt auf der SD-Karte und wird alle fünf Minuten beschrieben.
    • Ich habe meinen ersten Pi immer noch. Vermutlich ist es ein Pi 1B.
      Er hat mehrere Installationen hinter sich, ist jetzt aber ein Backup-DNS-Server. Dem Dateisystem nach wurde er seit 2018 als Pi-hole genutzt und läuft, abgesehen von ein paar Neustarts und Umzügen, praktisch 24/7.
      Auf die SD-Karte wird nichts geschrieben; alles geht in den RAM unter /dev/shm. Wenn Pi-hole selten einmal ausfällt, kann es die Listen einfach neu holen, und ohnehin werden sie täglich heruntergeladen.
    • Bei mir ist es genauso. Ich habe zwei Raspberry Pi 3 und betreibe darauf seit 2019 Pi-hole zur Werbeblockierung.
      Später habe ich sie auch als lokalen DNS und Tailscale-Nodes genutzt. Manchmal habe ich sie monatelang nicht neu gestartet; die längste Uptime lag bei etwa elf Monaten. Sie waren sehr robust. An einer USV zu hängen hilft definitiv.

  • Es hieß: „Einen Raspberry Pi wochen-, monate- oder jahrelang ohne Eingriff online zu halten, ist gewissermaßen eine Kunst.“ Ich boote dagegen einen NetBSD-Kernel mit eingebettetem Dateisystem.
    Zum Beispiel nutze ich den INSTALL-Kernel oder einen Custom-Kernel. Direkt nach dem Booten kann man die SD-Karte herausziehen und optional in angeschlossenen Speicher chrooten.
    So läuft das wochen-, monate- oder jahrelang. Die vom Blogautor genannten Probleme habe ich nicht erlebt.
    Das einzige Problem, das ich gefunden habe, betrifft bei Verwendung eines Gehäuses den Bereich des Stromanschlusses. Mit einem Ersatzkabel kann die Verbindung zum Beispiel schwach sein. Bei neueren Pis ist das vielleicht besser geworden.
    Allerdings kann man Ähnliches über die meisten Computer sagen. Kabel und Stecker sind meist schwache und billige Komponenten. Wenn durch Bewegung die Stromversorgung unterbrochen wird, startet der Pi automatisch neu.