Kernel Oops kapag nagsisimula ang VPN: ebidensyang sulit itago

Ang pagsisimula ng VPN client ay isang maginhawang timestamp, hindi sanhi, at ang pagkakaibang iyon ang nagtatakda kung ano ang susunod na mangyayari. Kapag may kernel Oops na nangyari malapit sa sandaling iyon, ang pagpipilian ay sa pagitan ng pagkolekta ng magagamit na ulat ng fault at ng pag-uudyok ng parehong crash ng lima pang beses sa isang production machine. Itago ang apat na bagay bago mag-reboot: ang eksaktong kernel build, ang unang fault trace, ang taint state at isang maikling paglalarawan ng lahat ng iba pang nagbago sa parehong minuto. Ang natitira ay interpretasyon, at ang interpretasyon ay maaaring maghintay hanggang ang ebidensya ay nasa ligtas na lugar.

Hulihin ang unang fault, hindi ang huling linya

Ang unang Oops sa log ang mahalaga, dahil ang bawat kasunod na fault ay maaaring side damage mula sa kernel na hindi na malusog. Kopyahin ang header kasama ang call trace, dahil ang header ay may dalang instruksiyon na nabigo at ang register state na tumutukoy sa code path. Ang ulat na nagsisimula sa huling linya ay maliit ang halaga para sa sinumang magbabasa nito makalipas ang isang linggo.

Kung nag-reboot na ang makina, ang kernel buffer ng nakaraang boot ay madalas pang nasa journal, basta't naka-enable ang persistent storage noon. Basahin ito mula sa naka-save na file sa halip na likhain muli ang workload, dahil maaaring i-overwrite ng ikalawang reproduction ang kailangan mo. Kung saan hindi kayang magtago ng journal ng makina sa pagitan ng mga reboot, ang serial console o netconsole ang tanging paraan para maging visible ang fault.

I-lock ang build bago magbasa ng anumang simbolo

Ang mga pangalan ng function at offset ay may kahulugan lamang kaugnay ng binary na gumawa sa kanila, kaya itala ang kernel release string at ang build identifier ng distribution nang magkasama. Ang symbol file mula sa ibang build ay tumuturo sa maling linya nang buong kumpiyansa, na mas malala kaysa walang simbolo. Itago ang bersyon ng kernel package, hindi lamang ang upstream number, dahil maraming backport ang mga distribution.

Ang mga module sa labas ng tree ay may karapatan sa sariling linya sa record, dahil nililimitahan ng taint na kernel kung ano ang maaaring tapusin ng maintainer. Basahin ang taint value sa halip na hulaan ito mula sa listahan ng module.

Ang taint na hindi zero ay hindi akusasyon at hindi ginagawang walang halaga ang ulat. Sinasabi nito sa mambabasa kung aling mga component ang naka-load nang mangyari ang fault, at ang ilang flag ay nagiging dahilan para mababa ang priyoridad ng ulat dahil sa patakaran at hindi sa paghatol. Itala ang value, mga pangalan ng module at kung ang parehong hardware at workload ay nagpatakbo kailanman ng kernel na wala ang mga ito. Ang huling paghahambing na iyon ang naghihiwalay ng bagong regression sa matagal nang bug.

Paghiwalayin ang trigger sa depekto

Ang pagsisimula ng tunnel ay karaniwang gumagamit ng landas na dati nang umiiral: isang network driver, isang queue discipline, isang offload feature o isang power state. Ipinapaliwanag ng trigger kung kailan lumilitaw ang fault, hindi kung aling code ang mali, at ang pagtrato sa trigger bilang sanhi ay humahantong sa serye ng mga pagbabago sa configuration na walang inaayos.

Ang gumaganang naunang image ay ebidensya, hindi patunay. Kapag naghahambing, palitan ang isang component bawat boot, at itago ang mga resulta sa lugar na nananatili pagkatapos ng makina.

Suriin kung ano talaga ang magagamit ng maintainer

Basahin ang ulat gaya ng babasahin ito ng estranghero bago mo ipadala. Kung naroon ang configuration, ang eksaktong sequence at ang build identity, at naalis ang credentials, magagamit ang ulat. Kung screenshot ito ng stack trace, babalik ito na may kahilingan para sa parehong impormasyon. Inilalarawan ng gabay sa paghahanap ng kernel bug kung ano ang hitsura ng kapaki-pakinabang na trace at tugmang simbolo.

uname -r
cat /proc/sys/kernel/tainted
journalctl -k -b -1 --no-pager | sed -n '/BUG:/,/Call Trace/p'
dmesg -T | grep -A 40 'RIP:'

Ang bawat command sa itaas ay nagbabasa lamang ng state, at ang unang dalawa ay dapat patakbuhin bago ang susunod na reboot kung kaya pa itong sagutin ng makina. Kung saan hindi persistent ang journal, ang dalawang iyon lang ang muling gagana.

Alisin ang mga key, password at walang kaugnayang traffic, ngunit itago ang mga pangalan ng function at offset na kailangan ng isang tao para basahin ang trace. Ipadala ang materyal sa daan ng pag-uulat na naaangkop sa distribution o kernel, hindi sa pampublikong paste na may nakalakip na hostname. Pagkatapos ay maghintay ng tanong sa halip na umani ng mas maraming crash, dahil ang nahanap na fault laban sa tugmang build ang tanging resulta na nagpapaabante ng ulat. Kung walang bumalik, ang alternatibo ay isang kontroladong reproduction sa ekstrang hardware, hindi kailanman sa makinang umaasa ang ibang tao.