sitoctt/Posts/2023-01-28-Problemi-Hardwar...

153 lines
20 KiB
Markdown
Raw Normal View History

// % Title = 🤯 Quando i problemi hardware diventano mentali (maledetto Raspino)
// % CreatedOn = 2023-01-28
// % Downsync = /Posts/Problemi-Hardware-Diventano-Mentali.html
// % HTMLTitle = <span class="twa twa-🤯"><span>🤯</span></span> Quando i problemi hardware diventano mentali (maledetto Raspino)
// % Categories = Blog Tecnologia Rasperino
<h1><span class="twa twa-🤯"><span>🤯</span></span> Quando i problemi hardware diventano mentali (maledetto Raspino)</h1>
<p>Fino ad, ormai, 2 mesi fa, il mio <strong>regno del Rasperino</strong> era al suo <strong>splendore massimo</strong>: l'istanza Misskey, messa su giusto 2 settimane prima, <strong>andava alla grande</strong>, e ormai (quasi) tutto sembrava destinato a continuare per bene...<br>
E invece, <strong>sono subentrati i problemi</strong>. Diciamo che ci ho messo un pochino ad accorgermene, perché si sono sviluppati <strong>in modo</strong> stranamente <strong>graduale</strong>.</p>
2023-01-29 20:36:18 +01:00
<h2>Le crepe iniziali</h2>
<p>La prima cosa veramente <strong>strana</strong> la notai verso l'inizio di Dicembre, in cui mi accorsi che <strong>il sistema poteva crashare</strong> provando a fare un'operazione molto banale ma <strong>specifica</strong>: creare un grande archivio di file (compresso e non)... con qualunque programma.<br>
Questo piccolo inconveniente ha, a sua volta, causato una <strong>problematica secondaria</strong>... Ci arrivo.<br>
Comunque, <strong>non ci ho fatto</strong> troppo <strong>caso</strong>. Come potevo? Il resto, se non toccato, <strong>funzionava</strong>, <strong>a parte</strong> qualche leggera <strong>degradazione delle prestazioni</strong> dovuta al lavoro di Misskey stesso.</p>
2023-01-29 20:36:18 +01:00
<h3>Il primo crollo</h3>
<p>Ma poi, sono passate quelle altre 2 settimane di relativa pace, e io <a href="https://mastodon.uno/@octo/109508472717947364" rel="noopener nofollow" target="_blank">mi sveglio</a> con il <strong>server piantato</strong>, e che <strong>muore male</strong> dopo qualunque mio riavvio manuale (staccando e riattaccando l'alimentatore, è l'unico modo). <a href="https://mastodon.uno/@octo/109518037875867744" rel="noopener nofollow" target="_blank">Dopo 2 giorni</a> di <strong>ricerca molto scazzata</strong> non ho capito assolutamente qual'era la causa generale del problema, ma solo il sintomo più grave, e ormai <strong>mi stavo</strong> quasi <strong>per convincere</strong> che in qualche modo <em>mistico</em> Misskey da solo riuscisse ad abbattere tutto il server, che invece tornava a girare per bene senza quel particolare software in esecuzione. Beh, un fondo di logica nel mio ragionamento c'era, visto che comunque l'<strong>uso medio</strong> di CPU e RAM era <strong>alto</strong> (anche se non andava a saturare totalmente).<br>
Nei giorni ancora successivi, invece, con <strong>qualche test</strong> scopro che il server non <strong>si piantava per via del</strong> serverino di microblogging, ma per quello che gli fa da <strong>database</strong>: PostgreSQL (in Docker). Se eseguivo Misskey sul mio PC, ma lo lasciavo collegarsi al database sul Raspino, ecco che in pochi secondi, con l'arrivo di tante note, il server fruttato moriva.</p>
<p>Ormai, ad ogni modo, era per me chiara la necessità di <strong>installare qualcos'altro</strong>, perché mi ero convinta che Misskey fosse troppo pesante, e pazienza.<br>
Per ben 2 giorni <strong>ho provato Epicyon</strong>, una piattaforma a dir poco <strong>particolare</strong>... e <a href="https://sitoctt.octt.eu.org/Posts/2022-12-26-Epicyon-Piattaforma-del-Fediverso-Durata-2-Giorni.html" rel="noopener nofollow" target="_blank">l'esperienza non è stata proprio gradevolissima</a>, ma credo sia stata completa, visto che quattromila parole le ho cacciate fuori nel mio articolo dedicato. Subito dopo ho quindi deciso di dare una chance ad un altro software che non avevo mai visto prima, ossia <a href="https://github.com/superseriousbusiness/gotosocial" rel="noopener nofollow" target="_blank">GoToSocial</a>. Con quest'ultimo, nonostante sia dichiaratamente di qualità alpha (e infatti ha qualche problemino), mi sono trovata - perché ahimè ora è tutto finito... ci arrivo, ci arrivo - molto bene, ma <strong>non è questo il punto</strong>.</p>
2023-01-29 20:36:18 +01:00
<h3>Problemi sempre più sospetti</h3>
<p>Appena pochi giorni dopo, quei <strong>crash</strong> strani hanno ripreso a presentarsi, ma stavolta erano decisamente <strong>sospetti</strong>, perché l'<strong>utilizzo di risorse</strong> generale del sistema era <strong>basso</strong>. Io ho provato a leggere i <strong>log di sistema</strong> in maniera produttiva, ma la mia <strong>pazienza</strong> era ormai arrivata <strong>al limite</strong>, e con essa la mia lucidità, quindi ogni giorno cercavo il minimo errore sospetto ma leggibile, fissandomi su quello ed <strong>ignorando</strong> completamente <strong>l'errore illeggibile</strong> che mi stava sempre di fronte.</p>
<p>Ormai, giusto <strong>per disperazione</strong>, ma non perché avevo capito ragionando fosse quello il problema, mi decido a <strong>cambiare</strong> la schedina <strong>microSD</strong>, e adesso che l'ho fatto <strong>mi pento</strong> amaramente... <strong>di non averci provato prima</strong>! Il problema era quello, maremma scapestrata!<br>
Il bello è che il giorno prima avevo fatto un controllo dei file system (ext4), sia della schedina che del mio HDD USB, ed era uscito tutto (circa) pulito, perciò avevo escluso problemi hardware a priori: "<em>se i file non sono corrotti...</em>" ho pensato.<br>
Circa nello stesso momento (il fato ha deciso che l'aiuto dovesse arrivare tardi!), comunque, una persona mi ha dato <strong>una mano a capire</strong> che cavolo dicessero quelle righe indecifrabili, che erano una roba tipo...</p>
<style>
.highlight.plaintext:first-of-type { max-height: 80vh; }
</style>
<div class="highlight CodeScroll"><pre class="highlight plaintext"><code>Dec 27 06:32:35 kernel: [27230.964650] INFO: task kworker/2:0:21874 blocked for more than 860 seconds.
Dec 27 06:32:35 kernel: [27230.964693] Tainted: G C 5.15.76-v7+ #1597
Dec 27 06:32:35 kernel: [27230.964709] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 27 06:32:35 kernel: [27230.964723] task:kworker/2:0 state:D stack: 0 pid:21874 ppid: 2 flags:0x00000000
Dec 27 06:32:35 kernel: [27230.964760] Workqueue: events_freezable mmc_rescan
Dec 27 06:32:35 kernel: [27230.964801] Backtrace:
Dec 27 06:32:35 kernel: [27230.964824] [&lt;80a4ff38&gt;] (__schedule) from [&lt;80a50a7c&gt;] (schedule+0x7c/0x134)
Dec 27 06:32:35 kernel: [27230.964868] r10:81f90800 r9:ffffe000 r8:00000000 r7:00000000 r6:60000013 r5:8d368000
Dec 27 06:32:35 kernel: [27230.964884] r4:ffffe000
Dec 27 06:32:35 kernel: [27230.964896] [&lt;80a50a00&gt;] (schedule) from [&lt;8083f658&gt;] (__mmc_claim_host+0xe0/0x238)
Dec 27 06:32:35 kernel: [27230.964929] r5:81f90a18 r4:00000002
Dec 27 06:32:35 kernel: [27230.964942] [&lt;8083f578&gt;] (__mmc_claim_host) from [&lt;8083f7e8&gt;] (mmc_get_card+0x38/0x3c)
Dec 27 06:32:35 kernel: [27230.964979] r10:baaf8205 r9:00000000 r8:baaf8200 r7:00000080 r6:baaf4b80 r5:00000000
Dec 27 06:32:35 kernel: [27230.964994] r4:81f91800
Dec 27 06:32:35 kernel: [27230.965007] [&lt;8083f7b0&gt;] (mmc_get_card) from [&lt;80849238&gt;] (mmc_sd_detect+0x24/0x7c)
Dec 27 06:32:35 kernel: [27230.965039] r5:81f90800 r4:81f90800
Dec 27 06:32:35 kernel: [27230.965052] [&lt;80849214&gt;] (mmc_sd_detect) from [&lt;80841ca4&gt;] (mmc_rescan+0xac/0x2d4)
Dec 27 06:32:35 kernel: [27230.965083] r5:81f90800 r4:81f90a7c
Dec 27 06:32:35 kernel: [27230.965096] [&lt;80841bf8&gt;] (mmc_rescan) from [&lt;8013e158&gt;] (process_one_work+0x250/0x57c)
Dec 27 06:32:35 kernel: [27230.965140] r9:00000000 r8:baaf8200 r7:00000080 r6:baaf4b80 r5:8e898f00 r4:81f90a7c
Dec 27 06:32:35 kernel: [27230.965153] [&lt;8013df08&gt;] (process_one_work) from [&lt;8013e4e4&gt;] (worker_thread+0x60/0x5c4)
Dec 27 06:32:35 kernel: [27230.965195] r10:baaf4b80 r9:81003d00 r8:baaf4b98 r7:00000008 r6:baaf4b80 r5:8e898f18
Dec 27 06:32:35 kernel: [27230.965210] r4:8e898f00
Dec 27 06:32:35 kernel: [27230.965223] [&lt;8013e484&gt;] (worker_thread) from [&lt;80146804&gt;] (kthread+0x178/0x194)
Dec 27 06:32:35 kernel: [27230.965264] r10:837c4000 r9:8d3a7e74 r8:00000000 r7:8e898f00 r6:8013e484 r5:8285ee00
Dec 27 06:32:35 kernel: [27230.965279] r4:8d0d3640
Dec 27 06:32:35 kernel: [27230.965291] [&lt;8014668c&gt;] (kthread) from [&lt;801000d4&gt;] (ret_from_fork+0x14/0x20)
Dec 27 06:32:35 kernel: [27230.965321] Exception stack(0x837c5fb0 to 0x837c5ff8)
Dec 27 06:32:35 kernel: [27230.965341] 5fa0: 00000000 00000000 00000000 00000000
Dec 27 06:32:35 kernel: [27230.965363] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Dec 27 06:32:35 kernel: [27230.965383] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
Dec 27 06:32:35 kernel: [27230.965405] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8014668c
Dec 27 06:32:35 kernel: [27230.965420] r4:8285ee00
</code></pre></div>
<p><strong>Ogni volta</strong> che succedeva un errore del genere, tutto <strong>il sistema moriva</strong> malissimo: <strong>malattie</strong> ai piccoli bot, <strong>morte</strong> al server HTTP (nginx), <strong>lesioni</strong> ai miei aggregatori di articoli e feed (wallabag e FreshRSS), <strong>ciao per sempre</strong> a qualunque cosa mi permetta di aprire una console via Internet sul Rasperino (SSH, Telnet, e pure un server arrangiato con netcat). L'unica cosa che continuava a funzionare è lo <strong>sputo costante di</strong> questo preciso tipo di <strong>errori</strong> nel file di log.<br>
Adesso, so che <em>sono mona forte</em>, ma con tutti 'sti numeri strani di mezzo <strong>io non riuscivo</strong> assolutamente a vedere parole come <code class="prettyprint">mmc_get_card</code> o <code class="prettyprint">mmc_sd_detect</code>! E quindi proprio non capivo che forse, <em>ma proprio forse</em>, la <strong>microSD</strong> <em>cagona</em> che avevo scelto per il Raspi all'inizio di settembre (tra quelle libere in casa), quando ho rimesso sto povero computerino a lavorare da server, era <strong>tendente alla morte</strong>.</p>
<p><img src="[staticoso:CustomPath:Assets]/Media/Misc/microSD-8GB-Generic.webp" alt="La schedina microSD che è riuscita lentamente a portarmi alla pazzia. Notare l'assenza di marche."></p>
<p>Io non voglio dover ricorrere ai <strong>luoghi comuni</strong>, ma stavolta <strong>c'è poco da fare</strong>! Cioè, la foto parla da sola:</p>
<blockquote>
<p><em>La presenza di un marchio rinomato non è sicurezza di qualità, ma l'assenza di un marchio è certamente promessa di qualità assente.</em></p>
</blockquote>
<p>Nonostante sul PC la <strong>vecchia schedaccia sembri</strong> ancora <strong>funzionare</strong> - ho potuto constatare ciò perché almeno ce l'ho fatta a fare un dump dei dati - <strong>non voglio più averne a che fare</strong> per roba di questo tipo! Me la segno in mente come <em>malamente</em>, dunque.<br>
Altro <strong>tempo</strong> ancora fu allora <strong>perso</strong> nel flashare il dump su una nuova scheda, visto che le uniche altre due schede che avevo a disposizione sul momento erano rispettivamente 4 e 32 GB, e io proprio volevo far entrare (dopo aver cancellato vari log e cache, perché la precedente memoria era da 8 GB) tutto su quella da 4, ma nulla da fare; e alla fine 32 GB fu.</p>
2023-01-29 20:36:18 +01:00
<h2>La pace violata</h2>
<p>La cosa importante è che, <strong>messa la nuova SD</strong> nel <em>server lampone</em>, quegli errori terrificanti non si sono più presentati, e i grossi <strong>problemi</strong> sono <strong>spariti</strong>... o almeno così <strong>credevo, volevo, speravo</strong>.<br>
Se questo articolo, che sarebbe dovuto letteralmente uscire alla fine dell'anno scorso, esce solo ora, dei motivi ci sono. Subito dopo che ebbi fatto il cambio di scheda SD, <strong>preferii aspettare</strong> qualche giorno, per vedere se davvero le acque si fossero calmate, ed evitare di cantare vittoria troppo presto. <strong>Ho fatto bene!</strong></p>
2023-01-29 20:36:18 +01:00
<h3>Il disco sofferente</h3>
<p>Ahimè, infatti, quelle altre cose viste nei giorni passati nei log <strong>non erano</strong> degli enormi <strong>buchi nell'acqua</strong> (<em>ancora agitata</em>), in particolare gli <strong>errori</strong> che ho subito riconosciuto riguardare il <strong>disco USB</strong>.<br>
È una cosa che mi succedeva già in passato con un altro adattatore USB per dischi SATA da 2.5", addirittura su macchine diverse (nel periodo in cui ho usato la mia console Nintendo Switch come server...), ma con questo che uso ora non c'erano <strong>mai stati problemi</strong>. E però ora, a quanto vedo, <strong>si scollega</strong> dall'host in maniera <strong>casuale</strong>, <strong>facendo morire</strong> tutti quei <strong>processi</strong> che dipendono dai file che stanno su quel disco, come se di punto in bianco ci fossero attimi in cui non riceve abbastanza corrente. Con qualsiasi combinazione di adattatori SATA e cavetti USB (sia corti che lunghi), <strong>il disco funziona</strong> ancora alla grande <strong>su PC</strong>, quindi <strong>il problema è</strong> chiaramente <strong>il Raspino</strong>... ma vai a capire perché!</p>
<p>Mi dicono che <strong>le porte</strong> USB-A del Raspi fanno schifo di natura<sup>[<em>citazione richiesta (?)</em>]</sup>, ma il punto è che fino a poco tempo prima <strong>funzionavano</strong> (tutte e 4)! Che nel mio alimentatore si sia <em>spaccato un diodo</em>? Che sulla scheda di questo maledetto computer a singola scheda, un condensatore sia <em>saltato in aria</em>? Che l'elettricità a casa mia non sia più 230V, ma 229V, e quindi il trasformatore anziché dare 5 volt in output ne dà 4.98? <strong>...Ma che ne so.</strong><br>
Tornando al mondo reale, l'unica ipotesi sensata mi pare che sia questa: a furia di inserire e disinserire il connettore di alimentazione nella sua porta (micro USB-B 2.0, <em>quella grande cacata!!!</em>), i pin da una parte o i pad dall'altra si saranno consumati, quindi la loro superficie di contatto è più ridotta, quindi la resistenza elettrica è maggiore, e quindi il dispositivo viene alimentato con una tensione leggermente minore, e quando una periferica ha bisogno di assorbire molto, ecco <em>i patatrac</em>.</p>
2023-01-29 20:36:18 +01:00
<h3>Per tentare di risolvere</h3>
<p>Non avendo un altro <em>Raspone</em> uguale, e non avendo altri alimentatori 5V 3A, <strong>la verità non la scoprirò</strong> mai, <strong>ma la soluzione</strong> in qualche modo <strong>devo trovarla</strong> per forza.<br>
Dopo aver <strong>aspettato così tanto</strong> che i <strong>problemi</strong> al server sono diventati solo più grossi, e i <strong>downtime</strong> molto <strong>più frequenti</strong>, mi decido a <strong>comprare un cavo USB-A-Y</strong>. Alla peggio, se pure non avessi risolto, un cavo di questo tipo fa sempre comodo averlo perché - nonostante <strong>violi gli standard USB</strong> <sup id="fnref1"><a class="footnote-ref" href="#fn1">1</a></sup>- alcuni dispositivi danno tante rogne senza, e alcuni produttori di periferiche <em>merdose</em> addirittura consigliano di usare cavi di questo tipo in caso di problemi (e procedono tuttavia a <strong>non</strong> includerne uno in confezione, indecenti!).</p>
<p><strong>Arrivato il cavo</strong>, sistemo tutti i collegamenti e noto una cosa particolare: <strong>la corrente</strong> che viene dal secondo alimentatore USB per alimentare il disco, <strong>può</strong> risalire il cavo fino a <strong>rientrare nel Pi</strong>. Non è tanto <strong>il cavo</strong> il problema, che funziona e <strong>rispetta</strong> tutte le <strong>leggi della fisica</strong> (anche se non quelle dello standard USB), ma più il fatto che il Raspberry non abbia nemmeno, che so, dei diodi nelle porte USB-A. Ed è un problema che non sto scoprendo io, basta leggere <a href="https://forums.raspberrypi.com/viewtopic.php?t=44584" rel="noopener nofollow" target="_blank">sul forum ufficiale</a>. Ad ogni modo, ad avere un circuito così impostato:</p>
<ul>
<li><strong>Rischi</strong> per la strumentazione o l'ambiente circostante <strong>non ce ne sono</strong>, se si usano alimentatori per bene a monte, e i miei <em>dovrebbero</em> esserlo<sup id="fnref2"><a class="footnote-ref" href="#fn2">2</a></sup>;</li>
<li><strong>Problemi</strong> pratici <strong>ci sono, ma anche le soluzioni</strong> e gli arrangiamenti: potrei, come sul forum suggeriscono, applicare del nastro isolante sul pad +5V del connettore USB che va al Raspantino; ma per ora non ce n'è stato vero bisogno, l'unica cosa a cui devo fare attenzione è che le cose siano alimentate in questo ordine, quelle poche volte in cui mi trovo a dover fare un hard reset del sistema:
<ol>
<li><strong>Disco</strong> USB (collegato alla porta del cavo Y);</li>
<li><strong>Raspi</strong> (dalla sua porta di alimentazione);</li>
<li>Dopo un'attesa di almeno ~10 secondi, <strong>disco</strong> collegato al Raspberry (connettore dati del cavo Y collegato al Rasperino).</li>
</ol></li>
</ul>
<p>Non so perché, specialmente considerando che non serve per i riavvii software, ma senza questa procedura il boot può fallire.</p>
2023-01-29 20:36:18 +01:00
<h2>Finalmente, il riposo</h2>
<p>Alla fine, comunque, l'<strong>inferno</strong> sembra essere <strong>finito</strong>, e il <strong>server</strong> ora <strong>funziona</strong>.<br>
Le fiamme hanno fatto dei danni, però: i <strong>database</strong> di molti miei servizi ospitati si sono <strong>corrotti</strong>, e di 2 in particolare (GoToSocial, che dicevo prima, e Peka, un chatbot basato su una catena di Markov) <strong>ho backup troppo vecchi</strong> (di settimane prima) perché, con il server che moriva, i miei script di backup non riuscivano mai a lavorare... e quindi <strong>questi programmi</strong> ancora adesso sono <strong>offline</strong>, perché <strong>non ho</strong> ancora avuto <strong>la forza di rassegnarmi</strong> a ripristinare i backup antichi.<br>
Ma io <strong>comprare il cavetto un po' prima</strong>, e spegnere il server nell'attesa, <strong>proprio no, eh?</strong></p>
<p><strong>Sperando</strong> che non succedano più cose di questo tipo nel breve futuro, altrimenti <strong>diventerò completamente e irrecuperabilmente pazza</strong> per via di questi dannati problemi hardware, vi saluto e vi auguro di non dover mai <em>mannaggiare</em> quanto me. 😔</p>
<h2>[:HNotesRefsHTML:]</h2>
<div class="footnotes">
<ol>
<li id="fn1">
<p>È stata una sorpresa anche per me, ma <strong>lo standard USB proibisce i cavi Y</strong>: si veda <a href="https://compliance.usb.org/index.asp?UpdateFile=Policies#72" rel="noopener nofollow" target="_blank">Update 72</a>; tradotto in italiano,</p><blockquote><em>L'uso di un cavo a "Y" (un cavo con due connettori A) è vietato su qualsiasi periferica USB. Se una periferica USB richiede una potenza superiore a quella consentita dalla specifica USB per la quale è stata progettata, deve essere auto-alimentata.</em></blockquote> E insomma, che belle le regole, però poi arriva la realtà e la pensa un po' diversamente. Tutto <strong>il mondo reale usa cavi Y</strong> senza farsi troppe <em>paturnie</em>.&nbsp;<a href="#fnref1"></a><p></p>
</li>
<li id="fn2">
<p>(Entrambi <strong>5V</strong>) </p><ul><li>Per il <strong>Pi</strong>, un alimentatore <strong>3A</strong> (appena sopra <a href="https://github.com/raspberrypi/documentation/blob/develop/documentation/asciidoc/computers/raspberry-pi/power-supplies.adoc" rel="noopener nofollow" target="_blank">il suggerito dalla Raspberry Foundation</a>) che era incluso in un kit (computerino escluso) di accessori per il Raspante, di <strong>Aukru</strong>. Aò, dopo anni non è esploso, poi le recensioni erano buone comunque, e ancora questa marca vende nuovi alimentatori, e allora va bene...</li><li>Per l'alimentazione <strong>supplementare</strong>, un blocchetto <strong>1A</strong> che era incluso nella confezione del mio vecchio telefono <strong>Huawei</strong> (commercializzato anche in Europa) di bassa gamma, del 2017.</li></ul>&nbsp;<a href="#fnref2"></a><p></p>
</li>
</ol>
</div>