Spustíte klienta, terminál vypíše Segmentation fault (core dumped) a nasledujúca hodina padne na opätovné flashovanie karty. Táto správa opisuje, ako jeden proces v jednom okamihu zomrel. Nehovorí, že doska je poškodená, a nezbavuje podozrenia ani napájanie, ani úložisko, ani obraz.

Postupujte od riadku, ktorý shell vypísal, späť k procesu za ním. Užitočné fakty sú, ktorý spustiteľný súbor zlyhal, v akom prostredí a v ktorej fáze spojenia.

Začnite riadkom, ktorý vypísal shell

Názov vo vašom príkaze je často obal alebo spúšťač, ktorý štartuje iný binárny súbor, takže overte, ktorý spustiteľný súbor jadro naozaj ukončilo. Zapíšte plnú cestu, verziu balíka a aplikácie, architektúru, verziu OS a jadra, účet, ktorý ho spustil, a presný čas. Shellový príkaz pomenovaný po VPN ľahko spustí pomocný proces a záznam pomenuje tento pomocný proces. Kopírovanie verzie z balíka nainštalovaného minulý mesiac nič nehovorí o tom, čo bežalo.

Poznamenajte, čo pádovi bezprostredne predchádzalo: štart, parsovanie profilu, autentifikácia alebo relácia, ktorá už prenášala prevádzku. Tieto štyri fázy zúžia hľadanie oveľa viac ako slovo segfault. Uchovajte krátke okno logov okolo udalosti a nechajte dohady o tom, ktorá nedávna zmena to spôsobila, kým to záznam nepovie.

Zistite, či existuje obraz pamäte

Referencia k core súboru opisuje dump ako obraz pamäte procesu zapísaný pri ukončení a uvádza aj podmienky, ktoré tomu zápisu bránia. Medzi ne patrí nulový limit prostriedkov a core vzor, ktorý dump smeruje inam než do pracovného adresára. Chýbajúci súbor s názvom core teda nič nedokazuje o tom, či k pádu došlo. Skontrolujte nastavený vzor a limit, kým usúdite, že systém nevyprodukoval žiadny dôkaz.

V systéme s kolektorom systemd podporovaný pohľad spája uložený záznam so spustiteľným súborom a časom. Záznam v journali a čitateľný obraz pamäte sú dva rôzne artefakty: politika uchovávania a oprávnenia vám môžu nechať jeden bez druhého. Opýtajte sa distribúcie alebo správcu aplikácie na diagnostický postup, ktorý podporujú, pretože stopa z iného buildu alebo inej sady knižníc zvyčajne plytvá ich časom.

sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn

Tie čítania zopakujte na stroji, ktorý naozaj spadol. Robiť ich na čistej inštalácii odpovedá na otázku, ktorú nikto nepoložil.

Berte dump ako materiál nesúci tajomstvá

Pamäť procesu môže obsahovať prihlasovacie údaje, kľúče relácií a obsah profilu, čo robí dump citlivejším než textový log vedľa neho. Redigovanie logu nič neurobí s nepriehľadným obrazom pamäte a bežné issue trackery držia prílohy oveľa dlhšie, než trvá vlákno podpory. Presuňte súbor súkromným kanálom, ktorý poskytuje dodávateľ alebo správca. Zverejnenie surového dumpu vo verejnom issue odhalí všetko, čo bolo v pamäti, keď proces zomrel, a kým to niekto nepreskúma, nemôžete vedieť čo.

Ak správca žiada stopu, opýtajte sa, z ktorého spustiteľného súboru a ktorých knižníc ju chce. Backtrace, ktorého rámce nezodpovedajú nahlásenému buildu, je ťažké dôverovať a ľahké zle prečítať.

Overte pôvod, kým niečo vymeníte

Overte pôvod balíka a integritu súborov u toho, kto vlastní inštaláciu, a pred akoukoľvek riadenou opravou uchovajte konfiguráciu a materiál identity. Neprepisujte jedinú kópiu dôkazu len preto, aby ste videli, či čistá inštalácia nabootuje. Čerstvý obraz, ktorý nabootuje, hovorí, že nový obraz nabootuje. Nehovorí, či starý obsahoval poškodený balík, zlyhávajúcu kartu alebo binárku, ktorá na tejto architektúre vždy mala spadnúť.

Ak zlyhávajú aj nesúvisiace programy alebo systém loguje chyby úložiska, napájania či jadra, uchovajte tieto pozorovania pre vyšetrovanie platformy. Rozširujú rozsah; nedokazujú, že každý segfault pochádza zo zlyhávajúcej RAM alebo poškodeného obrazu.

Po cielenej oprave zopakujte to isté povolené spustenie a tú istú operáciu VPN na tom istom hardvéri. Povedzte, ktorá chyba prestala a pod ktorou verziou. Čistý štart sám o sebe ani neidentifikuje vadný komponent, ani nepredpovie ďalšiu hardvérovú poruchu.

Súvisiace články