Kernel-Oops ved VPN-opstart: beviser, der er værd at gemme

At starte VPN-klienten er et praktisk tidsstempel frem for en årsag, og den forskel afgør, hvad der sker herefter. Når en kernel-Oops lander tæt på det øjeblik, er valget mellem at indsamle en brugbar fejlrapport og fremkalde samme nedbrud fem gange mere på en produktionsmaskine. Gem fire ting før du genstarter: det præcise kernel-build, det første fejlspor, taint-tilstanden og en kort beskrivelse af alt andet, der ændrede sig i samme minut. Resten er fortolkning, og fortolkningen kan vente, til beviserne er et sikkert sted.

Fang den første fejl, ikke den sidste linje

Den første Oops i loggen er den, der betyder noget, fordi hver senere fejl kan være følgeskade fra en kernel, der allerede er usund. Kopiér headeren sammen med call trace, da headeren bærer den fejlende instruktion og den registertilstand, der identificerer kodestien. En rapport, der starter ved den sidste linje, er meget lidt værd for den, der læser den en uge senere.

Hvis maskinen allerede er genstartet, ligger den forrige opstarts kernel-buffer ofte stadig i journalen, forudsat at vedvarende lager var aktiveret dengang. Læs den fra den gemte fil i stedet for at genskabe arbejdsbyrden, fordi en anden gengivelse kan overskrive det, du har brug for. Hvor maskinen ikke kan holde en journal på tværs af genstarter, er en seriel konsol eller netconsole den eneste måde, fejlen nogensinde bliver synlig.

Fastlæg buildet, før du læser nogen symbol

Funktionsnavne og offsets betyder kun noget i forhold til den binære fil, der frembragte dem, så notér kernel-udgivelsesstrengen og distributionens build-id sammen. En symbolfil fra et andet build peger på den forkerte linje med fuld sikkerhed, hvilket er værre end slet ikke at have noget symbol. Behold kernelpakkens version, ikke kun upstream-nummeret, fordi distributioner backporterer meget.

Moduler uden for træet fortjener deres egen linje i optegnelsen, da en taintet kernel begrænser, hvad en vedligeholder må konkludere. Læs taint-værdien i stedet for at udlede den fra en modulliste.

En taint forskellig fra nul er ikke en anklage og gør ikke rapporten værdiløs. Den fortæller læseren, hvilke komponenter der var indlæst, da fejlen skete, og nogle flag gør, at en rapport nedprioriteres af politik snarere end af vurdering. Notér værdien, modulnavnene og om det samme hardware og den samme arbejdsbyrde nogensinde kørte en kernel uden dem. Netop den sidste sammenligning adskiller en ny regression fra en mangeårig fejl.

Skil en udløser fra en defekt

At starte tunnelen udnytter normalt en sti, der allerede fandtes: en netværksdriver, en kødisciplin, en offload-funktion eller en strømtilstand. Udløseren forklarer, hvornår fejlen viser sig, ikke hvilken kode der er forkert, og at behandle udløseren som årsagen fører til en række konfigurationsændringer, der ikke retter noget.

Et fungerende tidligere image er bevis, ikke bevisførelse. Skift én komponent per opstart, når du sammenligner, og opbevar resultaterne et sted, der overlever maskinen.

Tjek, hvad vedligeholderen faktisk kan bruge

Læs rapporten, som en fremmed ville læse den, før du sender den. Hvis konfigurationen, den præcise sekvens og build-identiteten er der, og legitimationsoplysningerne er væk, er rapporten brugbar. Hvis det er et skærmbillede af et stack trace, kommer den tilbage med en anmodning om de samme oplysninger. Guiden til fejlfinding i kernen beskriver, hvordan et brugbart trace og matchende symboler ser ud.

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:'

Hver kommando ovenfor læser kun tilstand, og de to første bør køres før næste genstart, hvis maskinen stadig kan svare på dem. Hvor journalen ikke er vedvarende, er de to de eneste, der nogensinde vil virke igen.

Fjern nøgler, adgangskoder og uvedkommende trafik, men behold de funktionsnavne og offsets, som nogen skal bruge for at læse trace. Send materialet gennem den rapporteringsvej, der gælder for distributionen eller kernen, ikke en offentlig paste med et værtsnavn vedhæftet. Vent derefter på et spørgsmål i stedet for at høste flere nedbrud, fordi en lokaliseret fejl mod et matchende build er det eneste resultat, der flytter rapporten frem. Hvis intet kommer tilbage, er fallback en kontrolleret gengivelse på ekstra hardware, aldrig på maskinen, som andre mennesker er afhængige af.