Points à considérer pour un Raspberry Pi fonctionnant sur le long terme

 (dzombak.com)
1 points par GN⁺ 2024-02-18 | 1 commentaires | Partager sur WhatsApp
  • Pour maintenir un Raspberry Pi sans intervention pendant plusieurs semaines ou plusieurs années, il faut concevoir à l’avance des chemins de récupération automatique en cas de panne
  • Ce guide remplace l’ancien article sur la réduction de l’usure des cartes SD par une série plus large sur la fiabilité, qui regroupe les réponses selon les types de problèmes ainsi que des conseils de monitoring
  • Les principaux risques se répartissent entre échecs de connexion Wi‑Fi, interruptions de service, crashs dus à l’instabilité du matériel, du firmware ou des pilotes, ainsi que l’usure ou le manque d’espace de la carte SD
  • Les problèmes liés à la carte SD peuvent être atténués par le choix d’une microSD adaptée, l’absence d’utilisation du swap, la réduction des écritures, un système de fichiers racine en lecture seule et, si nécessaire, l’exécution de fsck
  • La désactivation du journaling peut réduire l’usure, mais augmente le risque de corruption du système de fichiers lors d’un crash ou d’une coupure de courant, ce qui ne va pas dans le sens d’un objectif de stabilité à long terme

Points de défaillance à examiner en priorité pour une exploitation de longue durée

  • Pour garder un Raspberry Pi en ligne sur le long terme, il faut se demander comment le Pi récupérera dans chaque situation de panne, tout en comparant les avantages et les risques de chaque solution
  • L’auteur utilise chez lui des Raspberry Pi comme émetteur FM basse consommation et comme moniteur d’énergie pour onduleur, entre autres usages
  • La série Raspberry Pi Reliability récapitule les types de problèmes réellement rencontrés et les façons de les résoudre, et inclut aussi surtout des conseils de monitoring avec Uptime Kuma
  • Cette série vise à être un guide plus complet que l’article existant sur la réduction de l’usure des cartes SD, les articles liés jouant le rôle de remplacements mis à jour

Réponses par type de problème et choix à éviter

À lire aussi

1 commentaires

 
GN⁺ 2024-02-18
Avis sur Hacker News

  • J’ai commencé à acheter à la place des mini PC Lenovo ; ils font 18 cm x 18 cm x 3 cm, donc restent très compacts
    On peut en trouver pour presque rien aujourd’hui, et ils ont un vrai boîtier ainsi qu’un refroidissement correct : https://psref.lenovo.com/syspool/Sys/PDF/ThinkCentre/ThinkCe...
    J’en ai un juste à côté de moi, avec un i5-8500T, 32 Go de RAM et 2 SSD ; avec l’auto-tuning de powertop, sa consommation au repos est actuellement de 5 W : https://wiki.archlinux.org/title/powertop

    • Pas de GPIO, I2C ni SPI. Si on cherche simplement un serveur petit et léger, c’est adapté, mais le Raspberry Pi est aussi populaire grâce à ses capacités d’E/S, rares sur les appareils grand public ou de bureau
      On pourrait ajouter une liaison série vers un microcontrôleur, mais cela rend la solution moins élégante
    • L’an dernier, j’ai migré le lecteur multimédia Kodi d’un RasPi 4 vers un mini PC N3350, et je ne le regrette pas
      Plus récemment, j’ai aussi déplacé mon NAS (N5105) et ma machine de services (3215U) vers des mini PC d’occasion et des Chromebook déverrouillés trouvés sur eBay ou en vide-greniers. C’est bon marché, la consommation électrique reste faible, et les performances de calcul n’ont tout simplement rien à voir avec celles du Pi
    • Je fais pareil, mais avec un Dell 7060
      En Australie, il y en a des milliers qui arrivent sur le marché en fin de leasing. Les puces 8500T ou 8700T sont excellentes, peuvent officiellement faire tourner Windows 11, et intègrent aussi le transcodage matériel, donc c’est parfait pour un serveur Plex
      J’en ai mis un à niveau avec 2 SSD de 2 To et 64 Go de RAM, et il tourne en 24/7 sans problème
    • Pareil pour moi. J’ai acheté du Dell reconditionné et c’est devenu bien moins pénible
      La carte SD était probablement la plus grosse source de problèmes, et si on prend en compte le coût d’ajout d’un SSD ou équivalent à un RPi, ce n’était plus vraiment rentable
    • Par rapport au matériel ARM, c’est aussi appréciable de pouvoir faire tourner pratiquement n’importe quelle distribution Linux

  • Le premier conseil ne devrait pas être d’activer le mode journalisé du système de fichiers
    Le premier conseil devrait être de monter le système de fichiers en lecture seule, de monter /var en mémoire, et d’envoyer tous les logs vers un nœud qui exécute un vrai UPS et NUT, plutôt que vers le RPi. Si le système de fichiers est en lecture seule ou temporaire, une coupure de courant devient pratiquement sans effet
    C’est peut-être excessif pour un seul RPi, mais l’auteur a dit qu’il en utilisait plusieurs dans toute la maison
    Il est aussi judicieux d’avoir des partitions système A/B et de mettre à jour en réécrivant toute la partition avant de basculer vers la partition active. Ainsi, même si la nouvelle version a un bug critique, il reste toujours une partition système fonctionnelle et la récupération est facile
    J’utilise avec succès cette approche depuis plus de 20 ans sur plusieurs petits PC et single-board computers dans divers rôles

    • L’auteur a mis, quelques lignes plus bas, un lien vers des conseils de configuration en lecture seule
      https://www.dzombak.com/blog/2021/11/Reducing-SD-Card-Wear-o...
    • Il faudrait utiliser tmpfs non seulement pour /var, mais aussi pour des emplacements comme /tmp. Cela devrait considérablement prolonger la durée de vie de la carte SD
    • Si l’on a des partitions système A/B et qu’on met à jour en réécrivant toute la partition, je serais curieux de connaître la procédure de mise à jour
      Comment crée-t-on la nouvelle image disque, et comment met-on à jour chaque appareil : en s’y connectant manuellement ou avec une forme d’automatisation ?
    • Si on monte le système de fichiers en lecture seule, je me demande comment on fait les mises à jour du système ou l’installation de nouveaux logiciels
    • Avec quelque chose comme Docker, monter /var en mémoire peut dépasser la mémoire disponible de l’appareil
      Il faudra peut-être déplacer /var/lib/docker vers un stockage auxiliaire

  • En 2011, j’ai déjà créé un produit commercial tournant sur les premiers plug computers de Global Scale Technologies
    Je n’en ai vendu que 20, mais ils ont tous été retournés à cause de problèmes de corruption de cartes SD, et j’ai dû en urgence basculer le système de fichiers racine en lecture seule. Depuis, j’apprécie beaucoup cette approche
    Ce premier produit commercial était un produit de sécurité domestique intégrant aussi quelques fonctions très modestes de domotique ; je l’ai publié en open source sous un nouveau nom en 2021, et il fonctionne maintenant sur des single-board computers de la famille Jetson : https://github.com/hcfman/sbts-install
    Il inclut désormais aussi des modèles YOLO avancés comme déclencheurs. Comme il était pensé comme un produit autonome, il prenait en charge HTTPS et disposait même d’une interface graphique qui encapsulait tout le travail autour des certificats. Cette fonctionnalité est restée dans la version open source, ce qui facilite l’utilisation de certificats auto-signés pour des appels REST entre appareils
    J’ai aussi conservé et étendu l’approche overlayFS avec mémoire multi-partitions, et, pendant l’installation, on commence par installer le système sbts-base, afin que d’autres puissent l’utiliser comme base pour leur propre système

    • J’ai eu une expérience similaire. J’avais converti un PC Pentium 2 à 5 dollars en station de travail fanless et silencieuse, en remplaçant le HDD par une carte CF
      Avec le temps, le système a commencé à se figer pendant 1 à 2 secondes à chaque écriture disque, et c’était assez pénible

  • À ceux qui veulent faire ce genre de chose, je recommanderais d’abord de vérifier si le besoin ne peut pas être couvert par une petite carte comme un ESP32
    La consommation électrique est bien plus faible, le prix se compte en quelques dollars, et cela suffit pour beaucoup d’usages. Si vous préférez l’écosystème Python, de nombreuses cartes prennent en charge à la fois MicroPython et CircuitPython
    Cela vaut la peine d’y jeter un œil, car on peut réduire à la fois le coût d’achat initial et la facture d’électricité sur la durée

    • Je comprends l’objection sur le coût en temps et la complexité de la programmation embarquée, mais pour un amateur, je pense que c’est au moins une excellente piste à envisager
      Les projets réalisés avec des microcontrôleurs ont été stables pendant des décennies de plus que mes projets basés sur des Pi, et il y a aussi moins de risque d’oublier de modifier la configuration SSH par défaut et de voir la machine rejoindre un botnet. Le défaut n’était pas pi:raspberry, d’ailleurs ?
      En dehors de MicroPython, la prise en charge de Rust no_std pour l’ESP32C3 s’améliore aussi chaque mois. Pour quelqu’un qui fait de petits projets domotiques pour le plaisir, ces contraintes supplémentaires peuvent au contraire rendre l’expérience plus amusante et gratifiante
      Cela dit, pour quelqu’un qui est déjà à l’aise avec Linux, un Pi est généralement bien plus simple, et d’après mon expérience le coût est au moins 10 fois supérieur. Il faut aussi intégrer à la décision la configuration supplémentaire nécessaire pour obtenir le même niveau de stabilité — démarrage sur SSD, démarrage réseau, système de fichiers racine en lecture seule, configuration d’un watchdog — ainsi que la consommation électrique plus élevée, surtout celle du Pi 5
    • Peut-on faire tourner un serveur multimédia sur un ESP32 ? Non
      Peut-on faire tourner un serveur de gestionnaire de mots de passe sur un ESP32 ? Non. Pi-hole ? Non. Contrôleur Unifi ? Non
      Ce genre de recommandation donne l’impression que certains imaginent que les gens utilisent un Pi pour piloter une porte de garage ou quelque chose du genre ; proposer un ESP32 comme remplaçant du Pi par réflexe n’aide pas vraiment
    • Les ESP32 et cartes apparentées sont assez géniaux, mais ils exigent une manière de penser complètement différente
      Quand quelque chose ne marche pas, on ne peut pas simplement brancher un HDMI et un clavier pour faire du débogage à la volée dans un environnement Linux standard avec tous les utilitaires habituels
    • Un Pi Zero coûte environ 1 dollar d’électricité par an
    • Sur des configurations un peu plus complexes récemment, j’utilise un Pi Zero avec plusieurs ESP8266/32 qui communiquent en HTTP et en Wi-Fi
      J’ai essayé MicroPython pour la première fois au lieu d’Arduino, et j’aime vraiment beaucoup ; de façon surprenante, c’est très stable. Avant, mes projets finissaient souvent par tomber en panne à long terme à cause des états d’alimentation du Wi-Fi, mais jusqu’ici je n’ai pas eu de problème avec l’architecture MicroPython

  • Dire que « tout finit généralement par un script qui vérifie périodiquement si la connexion Wi-Fi tient, et sinon redémarre l’interface Wi-Fi ou le Pi entier » n’est pas un bricolage, c’est une bonne pratique
    De la même façon qu’un serveur critique dans un datacenter doit disposer d’un accès hors bande comme IPMI ou une prise RPDU contrôlable à distance, un serveur critique situé dans un endroit distant difficile d’accès doit avoir un script watchdog
    Bien sûr, il faut l’adapter à l’usage en tenant compte de l’impact des redémarrages et de l’indisponibilité jusqu’au redémarrage, et on peut au minimum consigner les événements anormaux pour les analyser plus tard
    Quand j’ai déployé un RPi distant, la toute première chose que j’ai faite a été un simple script watchdog en Bash. Il ne servait pas seulement pour les problèmes de Wi-Fi, mais pour des dizaines de situations pouvant casser le système et être corrigées par un redémarrage

    • Aujourd’hui, sur la plupart des distributions, ce rôle de watchdog est assuré par init/PID 1, c’est-à-dire systemd
      Si on ne peut pas faire confiance à init pour gérer les services, on peut se demander d’où vient la garantie que le système fournit bien ses services
      On peut toujours le refaire avec des scripts, mais nous avons déjà dépassé ce stade. Je parle beaucoup de systemd, mais ce n’est pas du favoritisme ; il existe des alternatives
      La plupart des services n’exploitent pas correctement l’environnement dans lequel ils existent. On dirait qu’on s’attend à une personnalisation site par site, du genre déclarer qu’un serveur web dépend d’un montage précis
      Une directive souvent oubliée est PartOf=. Elle permet de lier le redémarrage d’un service ou d’une ressource à un autre
      Plus simplement, il est probable que NetworkManager offre un moyen de personnaliser les vérifications Wi-Fi/portail. Il n’est peut-être pas nécessaire d’aller jusqu’à une solution aussi radicale
    • De façon similaire, je surveille un routeur Wi-Fi et un modem câble avec un ESP8266. En cas de problème, je redémarre
      Pour le routeur, j’essaie de me connecter au bon SSID puis j’envoie un ping au routeur ; si l’un des deux échoue, je bascule vers un autre routeur. J’ai deux routeurs identiques avec la même configuration, et leur alimentation est branchée sur les contacts NO/NC d’un relais SPDT ; si l’un échoue, il suffit de changer l’état du relais pour passer sur l’autre
      Si le routeur est joignable, le watchdog récupère la page d’état du modem câble puis envoie un ping à n’importe laquelle de trois adresses IP qui semblent correspondre au CMTS ou à un équipement proche dans le réseau de l’ISP, afin de vérifier que l’infrastructure HFC fonctionne encore. En cas de panne qu’un redémarrage ne peut pas corriger, je préfère éviter de redémarrer pour rien
      Malheureusement, je n’ai pas trouvé de moyen d’avoir deux modems câble avec la même MAC et de basculer entre eux, et l’ISP n’autorise pas non plus deux modems sur le même compte ; donc si le modem câble tombe en panne, je n’ai pas d’autre choix que de le redémarrer et d’espérer que ça reparte
      J’y ai ajouté un rack de batteries capable de faire tourner le routeur et le modem pendant plus de 30 heures en cas de coupure de courant, et depuis sa mise en place en mai 2020, l’ensemble est resté en ligne presque en permanence. Le code est affreux, mais dans les faits, c’est très robuste
    • Tout à fait d’accord. Les watchdog timers sont indispensables sur les microcontrôleurs et les ordinateurs censés faire tourner du logiciel « pour toujours »
      Même avec un code et une conception parfaits, il peut arriver des choses qu’on ne peut pas empêcher, et un watchdog timer permet de casser une boucle infinie et de réinitialiser le système. Il y a aussi les rayonnements cosmiques qui inversent des bits, les baisses de tension momentanées, et sur Raspberry Pi il faut en plus se soucier de la corruption de la carte SD
      À ma connaissance, le Raspberry Pi dispose d’un watchdog timer matériel intégré. C’est aussi le cas des Arduino, c’est certain
    • C’est à la fois une bonne pratique et un bricolage. Cela ne devrait pas être nécessaire, mais comme les bugs existent, ça le devient

  • J’ai fait tourner des milliers de Pi en production pendant presque 10 ans, et je commence maintenant à migrer vers x86
    Le rapport performance/prix du Pi n’est plus ce qu’il était. J’ai présenté cette expérience récemment à la State of Open Con : https://youtu.be/vX-qK9mxKZI

    • En tant que collègue du CEO d’une entreprise de signalétique numérique sur Raspberry Pi, j’ai été surpris que la présentation ne mentionne pas la prise en charge du secure boot disponible à partir du Pi 4
      Nous ne l’utilisons pas encore dans notre service, mais d’après la documentation, cela semble assez solide et peut protéger les données sur le disque/la carte SD
      Nous restons globalement très satisfaits du Pi, et le passage à une API plus ouverte comme Mesa/DRM/KMS/FFmpeg semble désormais très prometteur maintenant que c’est enfin exploitable
      Notre usage principal reste la signalétique numérique, donc les performances brutes de calcul comptent peu. Le décodage vidéo, qui représente l’essentiel du coût, est évidemment accéléré, et la compatibilité ascendante possible sur Pi est excellente. Nous avons encore des clients qui font tourner des Pi1B+ depuis presque 10 ans avec la dernière version de notre OS
    • Il faut prendre en compte la manière dont on l’utilise. S’il y a beaucoup de temps d’inactivité, ARM est meilleur que x86
      Il faut aussi regarder la durée de vie, et là aussi ARM semble devoir durer plus longtemps que x86. En termes de modularité, ARM est également meilleur que x86, parce qu’il coûte moins cher de déployer plusieurs petits appareils
      En revanche, pour l’évolutivité — donc la viabilité économique dans l’économie actuelle — x86 est meilleur qu’ARM
      De plus, tous les graphiques devraient être évalués par watt. Dire qu’on est passé de 2 à 4 avec de meilleures performances n’a rien de nouveau ; ce qui compte, c’est si les performances par watt se sont améliorées
      Sous cet angle, on voit que le Raspberry Pi 5 n’apporte pas un gain de performances par watt aussi important qu’espéré. On a l’impression d’avoir atteint un plafond durable dans l’histoire de l’humanité
      Enfin, à ce stade, le seul espoir de progrès ne se situe pas au niveau des performances mais de l’ouverture, avec le JH7110, même si la prise en charge 3D est en retard
    • Je me demande s’il s’agit de piloter des écrans, ou d’équipements opérationnels utilisant les GPIO, comme du matériel d’assemblage en production
    • Je me demande aussi ce que signifie concrètement « migrer vers x86 »

  • Je n’ai fait absolument rien de tout cela, et pourtant certains Pi ont tourné des années sans problème jusqu’à leur remplacement par des modèles plus récents
    Les passerelles HomeKit/Zigbee et les enregistreurs de données sont aujourd’hui sur Pi 4. Au final, une bonne carte SD et une alimentation stable semblent être l’essentiel

    • D’accord. J’ai moi aussi fait tourner plusieurs Pi, et quand ils sont tombés en panne, c’était à cause d’une carte SD défectueuse
      Je trouve que pibenchmark est une bonne source d’information : https://pibenchmarks.com/
      Il faut absolument comparer les cartes SD avant d’acheter
    • Je pense que la taille de l’échantillon a plus d’impact sur l’expérience
      Quand on exploite suffisamment d’appareils, tout ce qui peut mal tourner finit par mal tourner, et de nouveaux modes de panne auxquels on n’aurait jamais pensé apparaissent aussi
    • Les anciennes versions de Raspbian OS, vers 2016 et avant, avaient l’enregistrement de l’heure d’accès activé, ce qui provoquait une écriture à chaque lecture de fichier
      C’est probablement pour cela qu’il y a eu ensuite autant de signalements de cartes corrompues
    • Pareil pour moi. J’ai quelques Pi3 qui tournent comme serveurs Cups depuis des années, et leur uptime n’est remis à zéro qu’en cas de coupure de courant. Les coupures sont d’ailleurs très rares
      Je n’ai rien fait d’autre que mettre Raspbian sur une carte micro SD, configurer Cups et brancher l’USB sur l’imprimante. Une autre machine gère une imprimante réseau. Depuis, je les ai simplement laissées tourner
    • C’est très irrégulier. Certains ont accumulé les problèmes sans fin, d’autres ont tenu longtemps sans souci. Je ne vois pas de schéma clair
      Maintenant, je les ai presque tous passés sur SSD. Sinon, c’est trop aléatoire

  • Je suis surpris que l’histoire des cartes SD ne soit pas évoquée en premier, et encore plus que l’article ne recommande pas le boot USB
    J’ai un Pi allumé presque 24/7 depuis des années, et je pense que s’il n’a pas eu de problème, c’est grâce à 1) une configuration d’Alpine qui évite presque complètement les accès disque, 2) l’absence de carte SD susceptible de se corrompre. Je ne sais pas pourquoi l’USB est plus fiable, mais empiriquement, ça l’a été

    • Ma configuration Argon Raspberry avec SSD est elle aussi stable
      La seule cause d’échec, c’est quand le courant saute. Une batterie capable de tenir 10 minutes semblerait largement suffisante
    • Je serais curieux de savoir comment configurer Alpine pour qu’il touche à peine au disque
      Par exemple, est-ce que tu parles de quelque chose comme https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode ?
    • J’ai eu beaucoup de cartes de Pi fonctionnant sans problème avec une SD. Mais il y en a eu une qui est soudain devenue extrêmement chaude, sur un Pi neuf que j’étais en train de configurer
      J’ai retiré la carte, et cette carte ainsi que le Pi suivant sont passés sur SSD USB. C’était un peu effrayant. Cela dit, comme je l’ai dit plus haut, j’ai aussi un Pi qui fait tourner un serveur Cups depuis des années sur micro SD sans aucun problème
    • Tout à fait d’accord. Toutes mes pannes de RPi venaient de la carte SD
      Deux de mes RPi bootent et tournent tous deux depuis l’USB, et fonctionnent très bien depuis des années
    • Pareil pour moi. Je boote depuis un SSD avec un M.2 HAT, et ça marche très bien

  • Depuis 2017, je fais tourner deux Pi presque en continu avec la même carte SD. Il y a eu 2 ou 3 coupures de courant
    L’un sert de serveur DNS/impression, l’autre fait tourner Kodi, avec les médias sur un NFS externe. La seule chose que j’ai faite a été de désactiver tous les logs, et je n’ai jamais eu de problème
    Les deux utilisent des cartes SanDisk de 2 Go. Je me souviens avoir vaguement pensé, de façon un peu naïve, « moins d’espace → densité de bits plus faible → meilleure fiabilité »

    • J’utilise log2ram (github/azlux/log2ram) et j’en suis satisfait
      Ça monte un disque RAM sur /var et ne copie les logs du disque RAM vers la carte SD qu’occasionnellement. Ça permet de consulter tous les logs sans marteler la carte SD
    • Je fais tourner Kodi sur un Pi 1 avec sa carte SD d’origine depuis presque 10 ans
      Il est allumé la plupart du temps, mais il m’arrive parfois de couper par erreur l’alimentation USB à laquelle il est branché. C’est un petit bloc d’alimentation à 5 ports, presque du même âge lui aussi, et dans ma configuration le bouton d’alimentation est trop facile à presser
    • J’ai un RPi qui tourne sans arrêt avec la même carte SD depuis 2014 et qui sert un site web météo
      En gros, j’ai monté tous les logs et les pages web sur tmpfs, et la base de données reste sur la carte SD avec une écriture toutes les 5 minutes
    • J’ai encore mon premier Pi. C’est probablement un Pi 1B
      Il a connu plusieurs installations, mais aujourd’hui c’est un serveur DNS de secours. D’après le système de fichiers, il sert de Pi-hole depuis 2018 et, à part quelques redémarrages et un déménagement, il tourne en pratique 24/7
      Rien n’est écrit sur la SD, tout part en RAM dans /dev/shm. Si Pi-hole tombe rarement, il suffit de retélécharger les listes, de toute façon elles sont téléchargées chaque jour
    • Pareil pour moi. J’ai deux Raspberry Pi 3 qui font tourner Pi-hole pour le blocage des pubs depuis 2019
      Plus tard, j’ai aussi commencé à les utiliser comme DNS local et nœud Tailscale. Il m’est arrivé de ne pas les redémarrer pendant plusieurs mois, et leur plus long temps de fonctionnement a été d’environ 11 mois. C’était très robuste. Les brancher sur un UPS aide clairement

  • Vous dites que « maintenir un Raspberry Pi en ligne pendant des semaines, des mois ou des années sans intervention est en quelque sorte un art », mais moi je démarre un noyau NetBSD avec système de fichiers intégré
    Par exemple, j’utilise le noyau INSTALL ou un noyau personnalisé. Juste après le démarrage, on peut retirer la carte SD, puis faire éventuellement un chroot vers un stockage connecté
    De cette façon, ça tourne pendant des semaines, des mois ou des années. Je n’ai jamais rencontré les problèmes mentionnés par l’auteur du blog
    Le seul vrai problème que j’ai trouvé concerne le connecteur d’alimentation quand on utilise un boîtier. Par exemple, avec un câble de remplacement, la connexion peut être faible. C’est peut-être mieux sur les Pi récents
    Mais on peut dire la même chose de la plupart des ordinateurs. Les câbles et connecteurs sont généralement des pièces fragiles et bon marché. Si le courant est coupé à cause d’un mouvement, le Pi redémarre automatiquement