Kernel-Oops når VPN starter: bevis som er verdt å ta vare på

Å starte VPN-klienten er et praktisk tidsstempel, ikke en årsak, og den forskjellen avgjør hva som skjer videre. Når en kernel-Oops lander nær det øyeblikket, står valget mellom å samle en brukbar feilrapport og å provosere frem det samme krasjet fem ganger til på en produksjonsmaskin. Ta vare på fire ting før du starter på nytt: det nøyaktige kernel-bygget, det første feilsporet, taint-tilstanden og en kort beskrivelse av alt annet som endret seg i samme minutt. Resten er tolkning, og tolkningen kan vente til bevisene er på et trygt sted.

Fang den første feilen, ikke den siste linjen

Den første Oops i loggen er den som betyr noe, fordi hver senere feil kan være følgeskade fra en kjerne som allerede ikke er sunn. Kopier hodet sammen med call trace, siden hodet bærer instruksjonen som feilet og registertilstanden som identifiserer kodestien. En rapport som starter på den siste linjen er lite verdt for den som leser den en uke senere.

Hvis maskinen allerede er startet på nytt, ligger kjernebufferen fra forrige oppstart ofte fortsatt i journalen, forutsatt at vedvarende lagring var aktivert da. Les den fra den lagrede filen i stedet for å gjenskape arbeidsbelastningen, fordi en andre reproduksjon kan overskrive det du trenger. Der maskinen ikke kan holde en journal på tvers av omstarter, er en seriell konsoll eller netconsole den eneste måten feilen noen gang blir synlig.

Fest bygget før du leser noe symbol

Funksjonsnavn og offset betyr bare noe mot binærfilen som produserte dem, så noter kernel-utgivelsesstrengen og distribusjonens byggidentifikator sammen. En symbolfil fra et annet bygg peker på feil linje med full sikkerhet, noe som er verre enn å ikke ha noe symbol i det hele tatt. Behold versjonen av kernel-pakken, ikke bare upstream-nummeret, fordi distribusjoner bakporterer mye.

Moduler utenfor treet fortjener sin egen linje i opptegnelsen, siden en taintet kjerne begrenser hva en vedlikeholder har lov til å konkludere. Les taint-verdien i stedet for å utlede den fra en modulliste.

En taint ulik null er ikke en anklage og gjør ikke rapporten verdiløs. Den forteller leseren hvilke komponenter som var lastet da feilen skjedde, og noen flagg gjør at en rapport nedprioriteres av policy snarere enn av skjønn. Noter verdien, modulnavnene og om den samme maskinvaren og arbeidsbelastningen noen gang kjørte en kjerne uten dem. Nettopp den siste sammenligningen skiller en ny regresjon fra en gammel feil.

Skill en utløser fra en defekt

Å starte tunnelen bruker normalt en sti som allerede fantes: en nettverksdriver, en kødisiplin, en offload-funksjon eller en strømtilstand. Utløseren forklarer når feilen vises, ikke hvilken kode som er feil, og å behandle utløseren som årsaken fører til en rekke konfigurasjonsendringer som ikke retter noe.

Et fungerende tidligere image er bevis, ikke bevisførsel. Endre én komponent per oppstart når du sammenligner, og oppbevar resultatene et sted som overlever maskinen.

Sjekk hva vedlikeholderen faktisk kan bruke

Les rapporten slik en fremmed ville lese den før du sender den. Hvis konfigurasjonen, den nøyaktige sekvensen og byggidentiteten er der, og påloggingsinformasjonen er fjernet, er rapporten brukbar. Hvis det er et skjermbilde av et stack trace, kommer den tilbake med en forespørsel om de samme opplysningene. Veiledningen for feilsøking i kjernen beskriver hvordan et nyttig spor og samsvarende symboler ser ut.

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 leser bare tilstand, og de to første bør kjøres før neste omstart hvis maskinen fortsatt kan svare på dem. Der journalen ikke er vedvarende, er de to de eneste som noen gang vil virke igjen.

Fjern nøkler, passord og uvedkommende trafikk, men behold funksjonsnavnene og offsetene som noen trenger for å lese sporet. Send materialet gjennom rapporteringsveien som gjelder for distribusjonen eller kjernen, ikke en offentlig innliming med et vertsnavn vedlagt. Vent deretter på et spørsmål i stedet for å høste flere krasj, fordi en lokalisert feil mot et samsvarende bygg er det eneste resultatet som flytter rapporten fremover. Hvis ingenting kommer tilbake, er fallbacken en kontrollert reproduksjon på ekstra maskinvare, aldri på maskinen som andre er avhengige av.