Segfault VPN klienta na Pi? Nejdřív zachyťte proces

Spustíte klienta, terminál vypíše Segmentation fault (core dumped) a následující hodina padne na přeflashování karty. Tahle zpráva popisuje, jak jeden proces v jednom okamžiku zemřel. Neříká, že je deska poškozená, a nezbavuje podezření ani napájení, ani úložiště, ani obraz.

Postupujte od řádku, který shell vypsal, zpět k procesu za ním. Užitečná fakta jsou, který spustitelný soubor selhal, v jakém prostředí a ve které fázi spojení.

Začněte řádkem, který vypsal shell

Název ve vašem příkazu je často obal nebo spouštěč, který startuje jiný binární soubor, takže ověřte, který spustitelný soubor jádro skutečně ukončilo. Zapište plnou cestu, verzi balíčku a aplikace, architekturu, verzi OS a jádra, účet, který jej spustil, a přesný čas. Shellový příkaz pojmenovaný po VPN snadno spustí pomocný proces a záznam pojmenuje tento pomocný proces. Kopírování verze z balíčku nainstalovaného minulý měsíc nic neříká o tom, co běželo.

Poznamenejte, co pádu bezprostředně předcházelo: start, parsování profilu, autentizace, nebo relace, která už předávala provoz. Tyto čtyři fáze zúží hledání mnohem víc než slovo segfault. Uchovejte krátké okno logů kolem události a nechte dohady o tom, která nedávná změna to způsobila, dokud to záznam neřekne.

Zjistěte, zda existuje obraz paměti

Reference k core souboru popisuje dump jako obraz paměti procesu zapsaný při ukončení a také uvádí podmínky, které tomu zápisu brání. Mezi ně patří nulový limit prostředků a core vzor, který dump směruje jinam než do pracovního adresáře. Chybějící soubor jménem core tedy nic nedokazuje o tom, zda k pádu došlo. Zkontrolujte nastavený vzor a limit, než usoudíte, že systém žádný důkaz nevytvořil.

V systému s kolektorem systemd podporovaný pohled spojuje uložený záznam se spustitelným souborem a časem. Záznam v journalu a čitelný obraz paměti jsou dva různé artefakty: politika uchovávání a oprávnění vám mohou nechat jeden bez druhého. Zeptejte se distribuce nebo správce aplikace na diagnostický postup, který podporují, protože stopa z jiného buildu nebo jiné sady knihoven obvykle plýtvá jejich časem.

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

Ta čtení zopakujte na stroji, který skutečně spadl. Dělat je na čisté instalaci odpovídá na otázku, kterou nikdo nepoložil.

Berte dump jako materiál nesoucí tajemství

Paměť procesu může obsahovat přihlašovací údaje, klíče relací a obsah profilu, což činí dump citlivějším než textový log vedle něj. Redigování logu nic neudělá s neprůhledným obrazem paměti a běžné issue trackery drží přílohy mnohem déle, než trvá vlákno podpory. Přesuňte soubor soukromým kanálem, který poskytuje dodavatel nebo správce. Zveřejnění surového dumpu ve veřejném issue odhalí vše, co bylo v paměti, když proces zemřel, a dokud to někdo neprohlédne, nemůžete vědět co.

Pokud správce žádá stopu, zeptejte se, z kterého spustitelného souboru a kterých knihoven ji chtějí. Backtrace, jehož rámce neodpovídají hlášenému buildu, je těžké uvěřit a snadné špatně přečíst.

Ověřte původ, než něco vyměníte

Ověřte původ balíčku a integritu souborů u toho, kdo instalaci vlastní, a před jakoukoli řízenou opravou uchovejte konfiguraci a materiál identity. Nepřepisujte jedinou kopii důkazu jen proto, abyste viděli, zda čistá instalace naběhne. Čerstvý obraz, který naběhne, říká, že nový obraz naběhne. Neříká, zda starý obsahoval poškozený balíček, selhávající kartu nebo binárku, která na této architektuře vždy měla spadnout.

Pokud selhávají i nesouvisející programy, nebo systém loguje chyby úložiště, napájení či jádra, uchovejte tato pozorování pro vyšetřování platformy. Rozšiřují rozsah; nedokazují, že každý segfault pochází ze selhávající RAM nebo poškozeného obrazu.

Po cílené opravě zopakujte stejné povolené spuštění a stejnou operaci VPN na stejném hardwaru. Řekněte, která chyba přestala a pod kterou verzí. Čistý start sám o sobě ani neidentifikuje vadnou součástku, ani nepředpoví další hardwarovou poruchu.