Segfault ng VPN client sa isang Pi? Kunin muna ang proseso

Sinimulan mo ang client, nagpi-print ang terminal ng Segmentation fault (core dumped), at ang susunod na oras ay napupunta sa muling pag-flash ng card. Inilalarawan ng mensaheng iyon kung paano namatay ang isang proseso sa isang sandali. Hindi nito sinasabi na sira ang board, at hindi rin nito pinapawalang-sala ang power supply, storage o image.

Magsimula sa linyang inilabas ng shell at bumalik sa prosesong nasa likod nito. Ang mga kapaki-pakinabang na katotohanan ay kung aling executable ang nabigo, sa anong kapaligiran at sa anong yugto ng koneksyon.

Magsimula sa linyang inilabas ng shell

Ang pangalan sa iyong command ay madalas na wrapper o launcher na nagpapasimula ng ibang binary, kaya tiyakin kung aling executable ang aktwal na tinapos ng kernel. Isulat ang buong path, bersyon ng package at application, arkitektura, release ng OS at kernel, account na nagpatakbo nito at ang eksaktong oras. Ang shell command na pinangalanan sa isang VPN ay madaling makapagpatakbo ng helper na proseso, at babanggitin ng talaan ang helper na iyon. Ang pagkopya ng version string mula sa package na ininstall mo noong nakaraang buwan ay walang sinasabi tungkol sa aktwal na tumakbo.

Itala kung ano ang direktang nauna sa pag-crash: startup, parsing ng profile, authentication, o session na nagpapadala na ng traffic. Ang apat na yugtong iyon ay mas nagpapaliit sa paghahanap kaysa sa salitang segfault. Itago ang maikling log window sa paligid ng pangyayaring iyon, at iwanan ang haka-haka kung aling kamakailang pagbabago ang naging sanhi hanggang sabihin ito ng talaan.

Alamin kung may memory image

Ang reference ng core file ay naglalarawan ng dump bilang image ng memory ng proseso na isinusulat sa pagtatapos, at inililista rin ang mga kondisyong pumipigil sa pagkasulat na iyon. Kasama sa mga kondisyong iyon ang resource limit na zero at core pattern na nagdadala ng dump sa ibang lugar maliban sa working directory. Kaya ang kawalan ng file na tinatawag na core ay walang pinapatunayan tungkol sa kung may nangyaring crash. Suriin ang naka-configure na pattern at ang limit bago magpasiya na walang ebidensyang ginawa ang system.

Sa system na gumagamit ng collector ng systemd, iniuugnay ng sinusuportahang view ang nakaimbak na talaan sa isang executable at oras. Ang journal entry at nababasang memory image ay dalawang magkaibang artefact: ang retention policy at mga pahintulot ay maaaring mag-iwan sa iyo ng isa nang wala ang isa. Tanungin ang distribution o ang maintainer ng application tungkol sa diagnostic workflow na sinusuportahan nila, dahil ang trace mula sa ibang build o ibang set ng library ay kadalasang nagsasayang ng kanilang oras.

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

Ulitin ang mga pagbabasang iyon sa makina na aktwal na nag-crash. Ang gawin ang mga ito sa bagong install ay sumasagot sa tanong na walang nagtanong.

Ituring ang dump bilang materyal na may dalang mga lihim

Ang memory ng proseso ay maaaring maglaman ng mga kredensyal, session key at nilalaman ng profile, na ginagawang mas sensitibo ang dump kaysa sa text log sa tabi nito. Ang pag-redact ng log ay walang nagagawa para sa opaque na memory image, at ang mga ordinaryong issue tracker ay nagtatago ng mga attachment nang mas matagal kaysa sa tinatagal ng isang support thread. Ilipat ang file sa pribadong channel na ibinibigay ng vendor o maintainer. Ang pag-post ng raw dump sa pampublikong issue ay naglalantad ng lahat ng nasa memory nang mamatay ang proseso, at hindi mo malalaman kung ano iyon hanggang may sumuri.

Kung humingi ng trace ang maintainer, itanong mula sa aling executable at aling mga library ang gusto nila. Ang backtrace na ang mga frame ay hindi tugma sa iniulat na build ay mahirap paniwalaan at madaling mabasa nang mali.

Suriin ang pinagmulan bago palitan ang anuman

I-verify ang pinagmulan ng package at integridad ng file sa may-ari ng installation, at pangalagaan ang configuration at identity material bago ang anumang kontroladong pag-aayos. Huwag i-overwrite ang nag-iisang kopya ng ebidensya para lang makita kung mag-boot ang malinis na install. Ang bagong image na nag-boot ay nagsasabi na nag-boot ang bagong image. Hindi nito sinasabi kung ang luma ay may sirang package, card na bumibigo o binary na palaging mag-fault sa arkitekturang ito.

Kung nabigo rin ang mga walang kaugnayang programa, o naglo-log ang system ng storage, power o kernel error, itago ang mga obserbasyong iyon para sa imbestigasyon ng platform. Pinalalawak nila ang saklaw; hindi nila pinapatunayan na ang bawat segfault ay galing sa bumibigong RAM o sirang image.

Pagkatapos ng naka-target na pagwawasto, ulitin ang parehong awtorisadong launch at parehong VPN operation sa parehong hardware. Sabihin kung aling pagkabigo ang tumigil at sa aling bersyon. Ang malinis na boot lamang ay hindi nakikilala ang depektibong bahagi at hindi rin hinuhulaan ang susunod na pagkasira ng hardware.