Segfault i klientit VPN në një Pi? Kapni së pari procesin
Shell-i printon segmentation fault dhe karta rishkruhet. Regjistroni ekzekutuesin, versionin dhe regjistrin e rrëzimit përpara se të zëvendësoni çfarëdo hardware.
Nisni klientin, terminali printon Segmentation fault (core dumped) dhe ora tjetër shkon për rishkrimin e kartës. Ai mesazh përshkruan si vdiq një proces në një çast. Nuk thotë se pllaka është dëmtuar dhe nuk e shfajëson as furnizimin me energji, as ruajtjen, as imazhin.
Filloni nga rreshti që shtypi shell-i dhe kthehuni te procesi pas tij. Faktet e dobishme janë cili ekzekutues dështoi, në çfarë mjedisi dhe në cilën fazë të lidhjes.
Filloni nga rreshti që shtypi shell-i
Emri në komandën tuaj është shpesh një mbështjellës ose nisës që nis një binar tjetër, prandaj konfirmoni cilin ekzekutues kernel-i përfundoi në të vërtetë. Shkruani rrugën e plotë, versionin e paketës dhe të aplikacionit, arkitekturën, versionin e sistemit dhe kernel-it, llogarinë që e nisi dhe kohën e saktë. Një komandë shell me emrin e një VPN nis lehtësisht një proces ndihmës dhe regjistri do të përmendë atë ndihmës. Kopjimi i vargut të versionit nga një paketë e instaluar muajin e kaluar nuk thotë asgjë për atë që ekzekutoi.
Shënoni çfarë i parapriu rrëzimit: nisja, analiza e profilit, vërtetimi ose një sesion që tashmë po kalonte trafik. Këto katër faza e ngushtojnë kërkimin shumë më tepër sesa fjala segfault. Ruani dritaren e shkurtër të regjistrave rreth atij eventi dhe lini mënjanë hamendësimet se cila ndryshim i fundit e shkaktoi derisa regjistri ta thotë.
Zbuloni nëse ekziston një imazh memorieje
Referenca e skedarit core e përshkruan dump-in si imazh i memories së procesit të shkruar në përfundim, dhe rendit gjithashtu kushtet që e pengojnë atë shkrim. Këto kushte përfshijnë një kufi burimesh zero dhe një model core që e drejton dump-in diku tjetër përveç drejtorisë së punës. Mungesa e një skedari me emrin core, pra, nuk provon asgjë nëse ndodhi një rrëzim. Kontrolloni modelin e konfiguruar dhe kufirin përpara se të përfundoni se sistemi nuk prodhoi provë.
Në një sistem që përdor mbledhësin e systemd, pamja e mbështetur lidh një regjistër të ruajtur me një ekzekutues dhe një kohë. Një hyrje journal-i dhe një imazh memorieje i lexueshëm janë dy artefakte të ndryshme: politika e mbajtjes dhe lejet mund t'ju lënë me njërin pa tjetrin. Pyetni shpërndarjen ose mirëmbajtësin e aplikacionit për rrjedhën diagnostike që ata mbështesin, sepse një trace i prodhuar nga një build tjetër ose një grup tjetër bibliotekash zakonisht u humb kohën.
sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn
Përsëritni ato lexime në makinën që u rrëzua vërtet. T'i bësh ato në një instalim të ri i përgjigjet një pyetjeje që askush nuk e bëri.
Trajtojeni dump-in si material që mban sekrete
Memoria e procesit mund të përmbajë kredenciale, çelësa sesioni dhe përmbajtje profili, gjë që e bën dump-in më të ndjeshëm se regjistri tekst përbrinjë. Redaktimi i regjistrit nuk bën asgjë për një imazh memorieje të errët, dhe gjurmuesit e zakonshëm të çështjeve i mbajnë bashkëngjitjet shumë më gjatë sesa zgjat një fije mbështetjeje. Zhvendoseni skedarin përmes kanalit privat që ofron furnizuesi ose mirëmbajtësi. Postimi i një dump-i të papërpunuar në një çështje publike zbulon çdo gjë që ishte në memorie kur vdiq procesi, dhe nuk mund ta dini çfarë ishte derisa dikush ta inspektojë.
Nëse një mirëmbajtës kërkon një trace, pyetni nga cili ekzekutues dhe cilat biblioteka e dëshiron. Një backtrace, kornizat e të cilit nuk përputhen me build-in e raportuar, është i vështirë për t'u besuar dhe i lehtë për t'u lexuar gabimisht.
Kontrolloni origjinën përpara se të zëvendësoni diçka
Verifikoni origjinën e paketës dhe integritetin e skedarëve përmes atij që zotëron instalimin, dhe ruani konfigurimin dhe materialin e identitetit përpara çdo riparimi të kontrolluar. Mos e mbishkruani kopjen e vetme të provës vetëm për të parë nëse nis një instalim i pastër. Një imazh i ri që niset tregon se imazhi i ri niset. Nuk tregon nëse i vjetri përmbante një paketë të korruptuar, një kartë që dështon ose një binar që gjithmonë do të kishte dështuar në këtë arkitekturë.
Nëse dështojnë edhe programe të palidhura, ose sistemi regjistron gabime ruajtjeje, energjie ose kernel-i, mbajini ato vëzhgime për hetimin e platformës. Zgjerojnë fushën; nuk provojnë se çdo segfault vjen nga RAM që dështon ose nga një imazh i korruptuar.
Pas një rregullimi të synuar, përsëritni të njëjtën nisje të autorizuar dhe të njëjtin operacion VPN në të njëjtin hardware. Thoni cili dështim u ndal dhe në cilin version. Një nisje e pastër vetëm sa vetë nuk identifikon një komponent me defekt dhe nuk parashikon dështimin e radhës të hardware-it.