लंबे समय तक चलने वाले Raspberry Pi के लिए ध्यान देने योग्य बातें

 (dzombak.com)
1 पॉइंट द्वारा GN⁺ 2024-02-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Raspberry Pi को कुछ हफ्तों से लेकर कई सालों तक बिना हस्तक्षेप चालू रखना है, तो फेलियर होने पर वह अपने-आप कैसे रिकवर करेगा, इसकी योजना पहले से बनानी चाहिए
  • यह गाइड पुराने SD कार्ड wear कम करने वाले लेख की जगह लेने वाली एक व्यापक reliability series का हिस्सा है, जिसमें समस्या के प्रकार के अनुसार उपाय और monitoring tips को साथ में समेटा गया है
  • मुख्य जोखिमों में WiFi कनेक्शन फेल होना, service रुक जाना, hardware·firmware·driver अस्थिरता से होने वाले crash, और SD कार्ड का घिस जाना या पूरी तरह भर जाना शामिल हैं
  • SD कार्ड से जुड़ी समस्याओं को सही microSD चुनकर, swap का उपयोग न करके, writes कम करके, read-only root filesystem अपनाकर, और ज़रूरत पड़ने पर fsck चलाकर कम किया जा सकता है
  • journaling को disable करने से wear कम हो सकता है, लेकिन crash या power outage के समय filesystem corruption का जोखिम बढ़ता है, इसलिए यह लंबी अवधि की stability के लक्ष्य के अनुकूल नहीं है

लंबी अवधि के संचालन में पहले देखने लायक failure points

  • Raspberry Pi को लंबे समय तक online रखना है, तो हर तरह की समस्या में Pi कैसे रिकवर करेगा यह देखना ज़रूरी है, और साथ ही हर समाधान के फायदे और जोखिम की तुलना भी करनी चाहिए
  • लेखक अपने घर में Raspberry Pi का उपयोग low-power FM transmitter और UPS energy monitor जैसी चीजों के लिए कर रहे हैं
  • Raspberry Pi Reliability series में लेखक द्वारा सीधे झेली गई समस्याओं के प्रकार और उनके समाधान को व्यवस्थित किया गया है, और इसमें मुख्य रूप से Uptime Kuma का उपयोग करके monitoring tips भी शामिल हैं
  • यह series पुराने SD कार्ड wear कम करने वाले लेख की तुलना में अधिक व्यापक guide बनने का लक्ष्य रखती है, और लिंक किए गए लेख updated replacement की तरह काम करते हैं

समस्या के प्रकार के अनुसार उपाय और किन विकल्पों से बचना चाहिए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-02-18
Hacker News की राय

  • इसके बजाय मैंने Lenovo mini PC खरीदना शुरू किया है; 18cm x 18cm x 3cm होने की वजह से वे अब भी बहुत छोटे हैं
    आजकल ये बहुत सस्ते मिल जाते हैं, और इनमें ठीक-ठाक केस व cooling भी होती है: https://psref.lenovo.com/syspool/Sys/PDF/ThinkCentre/ThinkCe...
    मेरे पास बिल्कुल बगल में एक चल रहा है: i5-8500T, 32GB RAM, 2 SSDs, और powertop auto-tuning के साथ idle power अभी 5W है: https://wiki.archlinux.org/title/powertop

    • GPIO, I2C, SPI नहीं हैं। अगर आप बस एक छोटा और हल्का server ढूंढ रहे हैं तो यह ठीक है, लेकिन Raspberry Pi अपनी input/output capabilities की वजह से भी लोकप्रिय है, जो consumer/office devices में दुर्लभ हैं
      microcontroller में serial connection जोड़ सकते हैं, लेकिन ऐसा करने पर solution उतना साफ-सुथरा नहीं रह जाता
    • पिछले साल मैंने Kodi media player को RasPi 4 से N3350 mini PC पर शिफ्ट किया, और कोई पछतावा नहीं है
      हाल ही में NAS (N5105) और service machine (3215U) को भी eBay या flea market से सेकंड-हैंड लिए mini PCs और unlocked Chromebook पर शिफ्ट किया। ये सस्ते हैं, power consumption कम रखते हैं, और compute performance Pi की तुलना में बिल्कुल अलग स्तर की है
    • मैं भी इसी तरह इस्तेमाल करता हूं, लेकिन Dell 7060 लेता हूं
      Australia में lease खत्म होने पर हजारों units बाजार में आ जाते हैं। 8500T या 8700T chips शानदार हैं, आधिकारिक रूप से Windows 11 चला सकते हैं, और hardware transcoding भी built-in है, इसलिए Plex server के लिए अच्छे हैं
      मैंने अपने एक में 2TB SSDs के 2 और 64GB RAM तक upgrade किया है, और वह बिना किसी समस्या के 24/7 चलता है
    • मेरे साथ भी यही है। Dell refurbished लेने के बाद झंझट काफी कम हो गया
      SD card शायद सबसे बड़ा समस्या स्रोत था, और RPi में SSD जैसी चीज जोड़ने की लागत जोड़ दें तो यह अब cost-effective नहीं रहा
    • ARM hardware की तुलना में यह भी अच्छा है कि आप लगभग कोई भी Linux distribution चला सकते हैं

  • पहली सलाह filesystem का journaling mode चालू करने की नहीं होनी चाहिए
    पहली सलाह यह होनी चाहिए कि filesystem को read-only mount करें, /var को memory में mount करें, और सभी logs को RPi पर नहीं बल्कि proper UPS और NUT चलाने वाले node पर भेजें। अगर filesystem read-only या temporary area में है, तो power outage असल में नुकसान नहीं करता
    एक RPi के लिए यह overkill हो सकता है, लेकिन लेखक ने कहा है कि वे घर में कई जगह कई units इस्तेमाल करते हैं
    साथ ही A/B system partitions रखना और upgrade के लिए पूरे partition को rewrite करने के बाद active partition बदलना भी अच्छा है। तब नए version में critical bug होने पर भी हमेशा एक working system partition बचा रहता है और recovery आसान हो जाती है
    इस तरीके से मैंने कई small/single-board PCs को अलग-अलग roles में 20 साल से ज्यादा समय तक अच्छे से चलाया है

    • लेखक ने कुछ lines नीचे read-only configuration advice का link दिया है
      https://www.dzombak.com/blog/2021/11/Reducing-SD-Card-Wear-o...
    • सिर्फ /var ही नहीं, /tmp जैसी जगहों के लिए भी tmpfs इस्तेमाल करना चाहिए। इससे SD card की उम्र काफी बढ़ जाएगी
    • अगर A/B system partitions रखकर और पूरे partition को rewrite करके upgrade करते हैं, तो मैं जानना चाहूंगा कि upgrade process कैसा होता है
      नया disk image कैसे बनाते हैं, और क्या हर device में login करके upgrade करते हैं या कोई automation है
    • filesystem को read-only mount करने पर system updates या नया software install कैसे करते हैं, यह जानना चाहूंगा
    • Docker जैसी चीज इस्तेमाल करने पर /var को memory में mount करने से device memory से ज्यादा usage हो सकता है
      /var/lib/docker को secondary storage में move करना पड़ सकता है

  • 2011 में मैंने Global Scale Technologies के शुरुआती plug computer पर चलने वाला एक commercial product बनाया था
    केवल 20 units बिके थे, लेकिन सभी SD card corruption की समस्या के कारण वापस आ गए, और हमें जल्दबाजी में root filesystem को read-only में बदलना पड़ा। उसके बाद से मुझे यह तरीका पसंद आने लगा
    वह शुरुआती commercial product एक home security product था जिसमें बहुत छोटी-सी home automation functionality भी थी, और 2021 में नए नाम से open source के रूप में जारी किया गया; अब यह Jetson series के single-board computers पर चलता है: https://github.com/hcfman/sbts-install
    अब इसमें advanced YOLO models भी triggers के रूप में शामिल हैं। क्योंकि इसे standalone product के तौर पर बनाया गया था, इसलिए इसमें HTTPS support था, और certificate-related कामों को संभालने वाला GUI भी था। यह feature open source version में भी मौजूद है, जिससे devices के बीच REST calls के लिए self-signed certificates इस्तेमाल करना आसान होता है
    साथ ही multi-partition memory overlayFS तरीका बनाए रखा और आगे बढ़ाया गया, और installation process में पहले sbts-base system install करवाया गया ताकि दूसरे लोग इसे अपने base system के रूप में इस्तेमाल कर सकें

    • मेरा भी मिलता-जुलता अनुभव है। मैंने 5 dollar वाले Pentium 2 PC को fanless और silent workstation में बदलते समय HDD को CF card से replace किया था
      समय के साथ, हर disk write पर system 1–2 seconds के लिए रुकने लगा, और यह काफी तकलीफदेह था

  • ऐसा करने की सोच रहे लोगों को मैं पहले यह देखने की सलाह दूँगा कि क्या ESP32 जैसे छोटे board से ज़रूरी काम नहीं हो सकता
    बिजली की खपत काफ़ी कम होती है, कीमत कुछ dollars के स्तर की है, और कई use cases के लिए पर्याप्त है। अगर आप Python side को पसंद करते हैं, तो कई boards MicroPython और CircuitPython दोनों support करते हैं
    शुरुआती खरीद लागत और लगातार आने वाला बिजली बिल घट सकता है, इसलिए देखना worthwhile है

    • embedded programming की time cost और complexity को लेकर आपत्ति समझ में आती है, लेकिन hobby users के लिए कम-से-कम विचार करने लायक यह एक शानदार recommendation है
      microcontroller से किए गए projects, Pi-based projects की तुलना में दशकों के पैमाने पर ज़्यादा stable रहे हैं, और basic SSH settings बदलना भूलकर botnet का हिस्सा बन जाने की चिंता भी कम होती है। default शायद pi:raspberry नहीं था क्या
      MicroPython के अलावा ESP32C3 के लिए no_std Rust support हर महीने बेहतर हो रहा है। मज़े के लिए छोटा home automation project करने वाले व्यक्ति के लिए अतिरिक्त constraints उलटे इसे और मज़ेदार व rewarding बना सकते हैं
      हालांकि जो लोग पहले से Linux से परिचित हैं, उनके लिए Pi आम तौर पर बहुत आसान है, और मेरे अनुभव में cost कम-से-कम करीब 10x महंगी पड़ती है। उसी स्तर की stability पाने के लिए SSD booting, network booting, read-only root filesystem, watchdog setup जैसी extra configuration और ज़्यादा power usage, खासकर Pi 5 की power, को भी decision में शामिल करना चाहिए
    • क्या ESP32 पर media server चला सकते हैं? नहीं
      क्या ESP32 पर password manager server चला सकते हैं? नहीं। Pi-hole? नहीं। Unifi controller? नहीं
      ऐसी recommendation शायद यह मानकर चलती है कि लोग Pi को garage door controller जैसी चीज़ों में इस्तेमाल करते हैं, लेकिन reflexively ESP32 को Pi replacement के रूप में सुझाना ज़्यादा मददगार नहीं है
    • ESP32 और related boards काफी शानदार हैं, लेकिन इनके लिए पूरी तरह अलग mindset चाहिए
      जब कुछ काम न करे, तो HDMI और keyboard लगाकर, common utilities से भरे mainline Linux environment में on-the-spot debugging नहीं कर सकते
    • Pi Zero का electricity bill साल में करीब 1 dollar आता है
    • हाल में थोड़ी ज़्यादा complex setup में मैं एक Pi Zero और कई ESP8266/32 को HTTP और Wi-Fi के ज़रिए communicate कराते हुए इस्तेमाल कर रहा हूँ
      Arduino के बजाय MicroPython पहली बार इस्तेमाल किया और यह सच में बहुत पसंद आया, और हैरानी की बात है कि यह बहुत stable है। पहले Wi-Fi power state की वजह से long-term में projects अक्सर टूट जाते थे, लेकिन अब तक MicroPython structure में कोई समस्या नहीं है

  • “Wi-Fi connection ठीक है या नहीं, इसे periodically check करना, और नहीं हो तो Wi-Fi interface या पूरी Pi को restart करने वाली script पर बात ज़्यादातर खत्म होती है” — यह hacking नहीं, best practice है
    जैसे data center के critical servers के लिए IPMI या remotely controllable RPDU outlet जैसा out-of-band connection होना चाहिए, वैसे ही मुश्किल से accessible remote location में मौजूद critical server के लिए watchdog script होनी चाहिए
    बेशक reboot के impact और reboot से पहले के downtime को use case के हिसाब से adjust करना चाहिए, और कम-से-कम बाद में investigation के लिए abnormal events record किए जा सकते हैं
    remote RPi deploy करते समय मैंने सबसे पहले एक simple Bash watchdog script बनाई थी। यह सिर्फ Wi-Fi issue के लिए नहीं, बल्कि उन दर्जनों situations के लिए थी जो टूट सकती हैं और reboot से ठीक हो सकती हैं

    • आजकल ज़्यादातर distributions में यह watchdog role init/PID 1, यानी systemd निभाता है
      अगर आप init पर भरोसा नहीं कर सकते कि वह services manage कर पाएगा, तो सवाल उठता है कि system services provide करेगा, इसकी guarantee कहाँ से आती है
      script से फिर से बना सकते हैं, लेकिन हम वह stage पार कर चुके हैं। systemd का ज़िक्र बहुत करता हूँ, पर favoritism नहीं है; alternatives भी हैं
      ज़्यादातर services अपने environment का ठीक से फायदा नहीं उठातीं। ऐसा लगता है जैसे site-specific customization की उम्मीद है, जैसे web server declare करे कि उसे कोई particular mount चाहिए
      एक directive जो अक्सर miss हो जाता है, वह PartOf= है। इससे एक service या resource के restart को दूसरे के साथ bind किया जा सकता है
      और भी simple तौर पर, NetworkManager शायद Wi-Fi/portal checks customize करने का तरीका देता होगा। पूरी तरह extreme जाने की ज़रूरत नहीं हो सकती
    • इसी तरह ESP8266 से Wi-Fi router और cable modem को monitor करता हूँ। समस्या आए तो reboot करता हूँ
      router के मामले में, यह proper SSID से connect करने की कोशिश करता है और router को ping करता है; दोनों में से कोई भी fail हो तो दूसरे router पर switch कर देता है। समान configuration वाले same routers के दो units रखे हैं, और power को SPDT relay के NO/NC contacts से जोड़ा है, ताकि एक fail हो तो सिर्फ relay state बदलकर दूसरे पर switch हो जाए
      router alive हो तो watchdog cable modem status page load करता है, और ISP network के अंदर CMTS या उसके पास की equipment लगने वाले तीन IPs में से किसी एक को ping करके check करता है कि HFC plant alive है या नहीं। क्योंकि अगर failure reboot से ठीक नहीं हो सकता, तो बेवजह reboot नहीं करना चाहता
      दुर्भाग्य से same MAC वाले दो cable modems रखकर switch करने का तरीका नहीं मिला, और ISP भी same account पर दो modems allow नहीं करता, इसलिए cable modem fail हो तो reboot करके अच्छे की उम्मीद करने के अलावा रास्ता नहीं
      इसके साथ एक battery rack लगाया है जो power outage के दौरान भी router और modem को 30 घंटे से ज़्यादा चला सकता है, और मई 2020 में बनाने के बाद से यह लगभग लगातार online रहा है। code भयानक है, लेकिन असल में बहुत robust तरीके से काम करता है
    • पूरी तरह सहमत। watchdog timer उन microcontrollers और computers के लिए essential है जो software को “हमेशा” चलाते हैं
      perfect code और design से भी न रोकी जा सकने वाली चीज़ें होती हैं, और watchdog timer infinite loop को तोड़कर reset कर देता है। spacecraft में bit flip होना या momentary voltage drop जैसी बातें भी होती हैं, और Raspberry Pi में SD card corruption की भी चिंता करनी पड़ती है
      मेरी जानकारी में Raspberry Pi में built-in hardware watchdog timer है। Arduino में तो निश्चित रूप से है
    • यह best practice भी है और hacking भी। इसकी ज़रूरत नहीं होनी चाहिए, लेकिन bugs मौजूद हैं, इसलिए ज़रूरत पड़ती है

  • लगभग 10 साल तक production environment में हज़ारों Pi चलाए हैं, और अब x86 पर शिफ्ट करना शुरू कर रहे हैं
    Pi का price-performance अब पहले जैसा नहीं रहा। हाल ही में State of Open Con में इस अनुभव पर presentation दी थी: https://youtu.be/vX-qK9mxKZI

    • Raspberry Pi digital signage CEO के साथी के तौर पर, presentation में Pi 4 से उपलब्ध secure boot support का ज़िक्र न होने पर हैरानी हुई
      हमारी service अभी इसे इस्तेमाल नहीं करती, लेकिन docs के हिसाब से यह काफ़ी मजबूत दिखता है और disk/SD पर data को protect कर सकता है
      हम अभी भी Pi से काफ़ी संतुष्ट हैं, और ज़्यादा खुले API Mesa/DRM/KMS/FFmpeg की ओर जाना भी अब usable हालत में आने लगा है, इसलिए बहुत promising लगता है
      मुख्य उपयोग अब भी digital signage है, इसलिए raw processing performance बहुत मायने नहीं रखती। cost का बड़ा हिस्सा बनने वाली video decoding तो निश्चित रूप से accelerate होती है, और Pi पर मिलने वाली backward compatibility शानदार है। हमारे कुछ customers अब भी लगभग 10 साल पुराने Pi1B+ लगातार चला रहे हैं और हमारे द्वारा दिए गए latest OS release का इस्तेमाल कर रहे हैं
    • इस्तेमाल के तरीके को ध्यान में रखना होगा। अगर idle state ज़्यादा रहती है, तो मेरी नज़र में ARM, x86 से बेहतर है
      lifespan भी देखना चाहिए, और वहाँ भी लगता है ARM, x86 से ज़्यादा चलेगा। modularity के मामले में भी ARM, x86 से बेहतर है, क्योंकि कई छोटे devices रखना सस्ता पड़ता है
      लेकिन scalability, यानी मौजूदा economy में business viability, x86 की ARM से बेहतर है
      साथ ही सारे graphs watts-per आधार पर होने चाहिए। 2 से 4 पर जाने पर performance बेहतर हुई, यह कोई नई बात नहीं; अहम यह है कि watts-per performance बेहतर हुई या नहीं
      इस तरह देखें तो पता चलता है कि Raspberry Pi 5 में watts-per performance improvement उम्मीद जितनी बड़ी नहीं है। लगता है मानव इतिहास में हम स्थायी रूप से peak पर पहुँच गए हैं
      अंत में, इस समय किसी progress की एकमात्र उम्मीद performance में नहीं बल्कि openness के लिहाज़ से JH7110 है, लेकिन इसका 3D support पीछे है
    • जानना चाहूँगा कि यह display चलाने के लिए है, या production assembly equipment जैसे GPIO इस्तेमाल करने वाले operational equipment के लिए
    • x86 पर शिफ्ट करने का ठोस मतलब क्या है, यह जानना चाहूँगा

  • इनमें से कुछ भी नहीं किया, फिर भी कुछ Pi नए models से replace होने तक कई साल बिना समस्या के चलते रहे
    HomeKit/Zigbee gateway और data logger अब Pi 4 हैं। आखिरकार लगता है अच्छा SD card और stable power supply ही core बात है

    • सहमत हूँ। मैंने भी कई Pi चलाए हैं, और जब failure हुआ तो वह SD card खराब होने की वजह से था
      pibenchmark जानकारी का अच्छा source लगता है: https://pibenchmarks.com/
      खरीदने से पहले SD cards की तुलना ज़रूर करनी चाहिए
    • मुझे लगता है sample size experience पर ज़्यादा असर डालता है
      अगर आप काफ़ी ज़्यादा devices operate करते हैं, तो जो कुछ गलत हो सकता है वह सब गलत होगा, और ऐसे नए failure modes भी दिखेंगे जिनके बारे में सपने में भी नहीं सोचा था
    • 2016 के आसपास और उससे पहले वाले पुराने Raspbian OS में access time recording enabled थी, इसलिए हर बार file पढ़ने पर write होता था
      उसके बाद damaged cards की reports ज़्यादा आईं, शायद वजह यही रही होगी
    • मेरा भी कुछ ऐसा ही है। कई Pi3 को Cups server के तौर पर सालों से चला रहा हूँ, और uptime सिर्फ power cut पर reset होता है। power cut भी बहुत rare हैं
      micro SD card पर Raspbian install करने, Cups set करने और printer से USB connect करने के अलावा कुछ नहीं किया। एक और unit network printer manage करता है। उसके बाद बस छोड़ दिया
    • बहुत inconsistent है। कुछ में लगातार problems आती रहीं, और कुछ लंबे समय तक ठीक रहे। कोई साफ pattern नहीं दिखता
      अब ज़्यादातर को SSD पर बदल दिया है। वरना बहुत dice roll जैसा लगता है

  • हैरानी हुई कि SD card वाली बात पहले नंबर पर नहीं थी, और यह देखकर और भी हैरानी हुई कि article USB boot suggest नहीं करता
    एक Pi को कई सालों से लगभग 24/7 चालू रख रहा हूँ, और मुझे लगता है कि issues न आने की वजहें हैं: 1) Alpine को ऐसा configure किया कि disk को लगभग touch न करे, 2) corrupt होने वाला SD card नहीं है। USB ज़्यादा reliable क्यों है, यह नहीं जानता, लेकिन अनुभव से तो ऐसा ही रहा

    • SSD लगे मेरे Argon Raspberry setup भी stable है
      fail होने की इकलौती वजह power cut है। 10 मिनट तक चलने वाली battery पूरी तरह काफ़ी होगी
    • Alpine को disk को लगभग touch न करने के लिए configure कैसे किया जाता है, यह जानना चाहूँगा
      जैसे क्या आपका मतलब https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode जैसी चीज़ से है
    • SD से बिना problem चलाए गए Pi cards बहुत रहे हैं। लेकिन सिर्फ एक में अचानक SD card बहुत गर्म हो गया, और वह एक नया Pi था जिसे अभी configure कर रहा था
      card निकाल दिया और उस card तथा अगले Pi को USB SSD पर बदलकर इस्तेमाल कर रहा हूँ। थोड़ा डरावना था। फिर भी जैसा ऊपर कहा, micro SD पर Cups server को कई सालों से बिना problem चलाने वाला Pi भी है
    • पूरी तरह सहमत। मेरे RPi failures सभी SD card की वजह से थे
      मेरे दो RPi दोनों USB से boot और run करते हैं, और सालों से अच्छे से चल रहे हैं
    • मेरा भी यही है। M.2 HAT के साथ SSD से boot करता हूँ और बहुत अच्छे से काम करता है

  • 2017 से एक ही SD कार्ड पर दो Pi लगभग लगातार चला रहा/रही हूँ। बिजली 2–3 बार गई होगी
    एक DNS/प्रिंट सर्वर है, और दूसरा Kodi है; मीडिया बाहरी NFS पर है। मैंने बस सारे logs बंद किए थे, और कभी कोई समस्या नहीं आई
    दोनों में SanDisk 2GB कार्ड इस्तेमाल हो रहे हैं। धुंधला-सा याद है कि मैंने भोलेपन में सोचा था, “कम जगह → कम bit density → बेहतर reliability”

    • मैं log2ram (github/azlux/log2ram) इस्तेमाल करता/करती आया/आई हूँ और नतीजों से संतुष्ट हूँ
      /var पर RAM disk mount करता/करती हूँ, और logs को RAM disk से SD कार्ड पर कभी-कभार ही copy करता/करती हूँ। इससे SD कार्ड पर बहुत ज्यादा writes किए बिना भी सारे logs देखे जा सकते हैं
    • मूल SD कार्ड के साथ ही Pi 1 पर Kodi लगभग 10 साल से चला रहा/रही हूँ
      यह ज्यादातर चालू रहता है, लेकिन कभी-कभी गलती से जुड़ा हुआ USB power supply बंद कर देता/देती हूँ। यह 5-port वाला छोटा power supply है और इसकी उम्र भी लगभग उतनी ही है; मेरे setup में इसका power button बहुत आसानी से दब जाता है
    • 2014 से एक RPi उसी SD कार्ड पर बिना रुके चल रहा है और weather website serve करता है
      मूल रूप से सभी logs और webpages को tmpfs पर mount किया है, और DB SD कार्ड पर है जिसमें हर 5 मिनट में write होता है
    • मेरा पहला Pi अब भी मेरे पास है। शायद Pi 1B होगा
      कई installations से गुजरा है, लेकिन अब backup DNS server है। filesystem देखने पर पता चलता है कि 2018 से Pi-hole के रूप में इस्तेमाल हो रहा है, और कुछ reboots व घर बदलने के समय को छोड़कर लगभग 24/7 चलता रहा है
      SD पर कुछ भी write नहीं करता/करती, सब कुछ /dev/shm में RAM पर भेजता/भेजती हूँ। Pi-hole कभी-कभार बंद हो जाए तो lists फिर से लेनी होती हैं, और वैसे भी वे रोज download होती हैं
    • मेरे साथ भी ऐसा ही है। मेरे पास दो Raspberry Pi 3 हैं, और 2019 से ad blocking के लिए Pi-hole चला रहा/रही हूँ
      बाद में इन्हें local DNS और Tailscale node के रूप में भी इस्तेमाल करना शुरू किया। कई महीनों तक reboot न करने के मौके भी आए, और सबसे लंबा uptime करीब 11 महीने था। बेहद मजबूत रहे। UPS से जोड़कर रखना निश्चित रूप से मदद करता है

  • कहा गया था कि “Raspberry Pi को कई हफ्तों, महीनों, सालों तक बिना दखल के online रखना अपने-आप में कुछ हद तक कला है”, लेकिन मैं embedded filesystem वाला NetBSD kernel boot करता/करती हूँ
    उदाहरण के लिए INSTALL kernel या custom kernel इस्तेमाल करता/करती हूँ। Boot के तुरंत बाद SD कार्ड निकाला जा सकता है, और वैकल्पिक रूप से जुड़े हुए storage में chroot करता/करती हूँ
    इस तरह यह हफ्तों, महीनों, सालों तक चलता है। ब्लॉग लेखक ने जिन समस्याओं का जिक्र किया, वे मैंने नहीं देखीं
    मुझे मिली एकमात्र समस्या case इस्तेमाल करते समय power connector की तरफ होती है। जैसे replacement cable इस्तेमाल करें तो connection कमजोर हो सकता है। नए Pi में शायद यह बेहतर हुआ हो
    लेकिन ज्यादातर computers के बारे में भी ऐसा ही कहा जा सकता है। Cables और connectors आमतौर पर कमजोर और सस्ते parts होते हैं। हिलने-डुलने से power कटे तो Pi अपने-आप reboot हो जाता है