În urmă cu câteva zile am avut parte de una din acele dimineți în care nimic nu funcționează așa cum ar trebui, deși aparent nu am făcut nimic.
Curentul a picat de două ori într-un interval scurt, la câteva secunde distanță. Un lucru minor pentru majoritatea oamenilor, dar pentru cineva care ține câteva servicii pornite non-stop acasă, două întreruperi consecutive înseamnă întotdeauna un mic haos de reparat după aceea.
Ce s-a întâmplat de fapt
NUC-ul principal s-a repornit singur, așa cum era de așteptat, pentru că are setată în BIOS opțiunea de a porni automat după ce revine alimentarea. Problema a apărut la un disc extern conectat printr-un enclosure USB cu chipset JMicron, cel pe care îl folosesc pentru o parte din date. Acesta nu a mai pornit automat odată cu revenirea curentului. NUC-ul a pornit, sistemul de operare a încărcat, dar discul a rămas oprit, needetectat de nimic în lsblk. A trebuit să merg fizic și să repornesc manual enclosure-ul ca discul să fie recunoscut din nou, lucru confirmat imediat după aceea în dmesg, unde apărea corect ca disc SCSI atașat.
Efectul de domino asupra serviciilor
Odată ce discul a fost din nou disponibil, m-aș fi așteptat ca totul să revină la normal fără alte surprize. Uptime Kuma a început brusc să arate totul ca nefuncțional, deși containerele păreau să ruleze normal. Verificând mai atent, problema nu era la serviciile în sine, ci la rezolvarea numelor de domeniu: orice cerere nslookup sau ping către un nume extern se termina cu SERVFAIL.
Am verificat mai întâi conectivitatea de bază către internet, cu ping direct către o adresă IP, și mergea perfect. Deci nu era o problemă de rețea fizică sau de router, ci ceva strict legat de rezolvarea numelor. Am continuat cu cat /etc/resolv.conf, care arăta clar că rezolvarea era delegată complet către rețeaua privată prin care leg dispozitivele între ele, adică Tailscale, cu adresa lui specială de MagicDNS, 100.100.100.100.
Setarea care lipsea
Verificând jurnalul serviciului cu journalctl -u tailscaled, am găsit exact momentul problemei: la boot, Tailscale a configurat DNS-ul cu o listă goală de resolvere din spate, DefaultResolvers:[], ceea ce înseamnă practic că orice cerere de rezolvare primea automat un refuz, fără nicio explicație vizibilă din exterior. MagicDNS rula, dar nu avea unde să trimită mai departe cererile pentru domenii din afara rețelei private.
Interesant e că, în mod normal, acest lucru nu ar fi trebuit să conteze deloc, pentru că fiecare mașină are propriul sistem local de rezolvare a numelor, configurat separat și folosit implicit. Dar exact în fereastra aceea de repornire, ceva a făcut ca rețeaua privată să preia controlul complet asupra rezolvării, cu accept-dns activat implicit, înlocuind temporar configurația locală funcțională. Asta explică și de ce, până la acest incident, nu întâmpinasem niciodată problema: pur și simplu nu depinsesem practic de acel mecanism până acum.
Soluția a fost să dezactivez temporar acel comportament automat cu tailscale set --accept-dns=false, să confirm că rezolvarea locală funcționează din nou, apoi să-l reactivez explicit cu tailscale set --accept-dns=true. De data asta, la reactivare, Tailscale a apucat să tragă corect lista completă de resolvere de la serverul central, iar rezolvarea a revenit la normal aproape instant.
Discul care nu vrea SMART
Cât timp am tot investigat, am încercat și să verific starea de sănătate a discului extern cu smartctl, ca să mă asigur că nu cumva enclosure-ul refuzase să pornească din cauza unei probleme mai grave la disc. Aici m-am lovit de o limitare separată: chipset-ul JMicron din enclosure nu translatează corect comenzile SAT necesare pentru SMART prin USB, indiferent de varianta încercată, -d sat, -d usbjmicron, -d scsi, cu sau fără -T permissive. E o limitare de firmware cunoscută la acest tip de punte, nu ceva ce se repară din partea sistemului de operare. Discul funcționează normal, dar monitorizarea SMART completă rămâne indisponibilă cât timp stă în acest enclosure.
Ce rămâne de învățat
Cel mai clar semnal din tot acest episod e că infrastructura de acasă are nevoie de un sistem de alimentare neîntreruptibilă, măcar pentru echipamentele critice. E un proiect pe care îl am deja în plan, dar care, ca orice proiect de acest fel, așteaptă momentul potrivit din punct de vedere financiar și de timp.
Până atunci, rămâne lecția practică: o pană de curent nu înseamnă doar oprire și repornire. Poate scoate la iveală dependențe ascunse între sisteme, comportamente care păreau stabile doar pentru că niciodată nu au fost puse cu adevărat la test. Uneori ai nevoie exact de un asemenea incident ca să vezi clar unde sunt punctele slabe ale propriei configurații, chiar dacă prețul plătit e o dimineață pierdută cu depanare în loc de altceva mai plăcut.
#blaugust2026
Comentarii