Kernel-Oops når VPN startar: prov som er verd å ta vare på

Å starte VPN-klienten er eit praktisk tidsstempel, ikkje ei årsak, og den skilnaden avgjer kva som skjer vidare. Når ein kernel-Oops landar nær det augneblinken, står valet mellom å samle ein brukbar feilrapport og å provosere fram det same krasjet fem gonger til på ein produksjonsmaskin. Ta vare på fire ting før du startar på nytt: den nøyaktige kernel-byggjen, det første feilsporet, taint-tilstanden og ei kort skildring av alt anna som endra seg i same minutt. Resten er tolking, og tolkinga kan vente til prova er på ein trygg stad.

Fang den første feilen, ikkje den siste linja

Den første Oops i loggen er den som tel, fordi kvar seinare feil kan vere følgjeskade frå ein kjerne som allereie ikkje er sunn. Kopier hovudet saman med call trace, sidan hovudet ber instruksjonen som feila og registertilstanden som identifiserer kodestien. Ein rapport som startar på den siste linja er lite verd for den som les han ei veke seinare.

Viss maskinen allereie er starta på nytt, ligg kjernebufferen frå førre oppstart ofte framleis i journalen, føresett at varig lagring var slått på då. Les han frå den lagra fila i staden for å gjenskape arbeidslasta, fordi ein andre reproduksjon kan skrive over det du treng. Der maskinen ikkje kan halde ein journal på tvers av omstartar, er ein seriell konsoll eller netconsole den einaste måten feilen nokon gong vert synleg.

Fest byggjen før du les noko symbol

Funksjonsnamn og offset tyder berre noko mot binærfilen som produserte dei, så noter kernel-utgåvestrengen og byggjeidentifikatoren til distribusjonen saman. Ei symbolfil frå ein annan byggje peikar på feil linje med full sikkerheit, noko som er verre enn å ikkje ha noko symbol i det heile. Hald på versjonen av kernel-pakken, ikkje berre upstream-nummeret, fordi distribusjonar bakportar mykje.

Modular utanfor treet fortener si eiga linje i oppteikninga, sidan ein tainta kjerne avgrensar kva ein vedlikehaldar har lov til å konkludere. Les taint-verdien i staden for å utleie han frå ei modulliste.

Ein taint ulik null er ikkje ei skulding og gjer ikkje rapporten verdilaus. Han fortel lesaren kva komponentar som var lasta då feilen skjedde, og nokre flagg gjer at ein rapport vert nedprioritert av politikk snarare enn av skjøn. Noter verdien, modulnamna og om den same maskinvara og arbeidslasta nokon gong køyrde ein kjerne utan dei. Nettopp den siste samanlikninga skil ein ny regresjon frå ein gammal feil.

Skil ein utløysar frå ein defekt

Å starte tunnelen brukar vanlegvis ein sti som allereie fanst: ein nettverksdrivar, ein kødisiplin, ein offload-funksjon eller ein straumtilstand. Utløysaren forklarar når feilen viser seg, ikkje kva kode som er feil, og å handsame utløysaren som årsaka fører til ei rekkje konfigurasjonsendringar som ikkje rettar noko.

Eit fungerande tidlegare image er prov, ikkje provføring. Endre éin komponent per oppstart når du samanliknar, og oppbevar resultata ein stad som overlever maskinen.

Sjekk kva vedlikehaldaren faktisk kan bruke

Les rapporten slik ein framand ville lese han før du sender han. Viss konfigurasjonen, den nøyaktige sekvensen og byggjeidentiteten er der, og påloggingsinformasjonen er fjerna, er rapporten brukbar. Viss det er eit skjermbilete av eit stack trace, kjem det tilbake med ei førespurnad om dei same opplysningane. Rettleiinga for feilsøking i kjernen skildrar korleis eit nyttig spor og samsvarande symbol 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:'

Kvar kommando ovanfor les berre tilstand, og dei to første bør køyre før neste omstart viss maskinen framleis kan svare på dei. Der journalen ikkje er varig, er dei to dei einaste som nokon gong vil verke igjen.

Fjern nøklar, passord og uvedkomande trafikk, men hald på funksjonsnamna og offsetane som nokon treng for å lese sporet. Send materialet gjennom rapporteringsvegen som gjeld for distribusjonen eller kjernen, ikkje ei offentleg innliming med eit vertsnamn vedlagt. Vent deretter på eit spørsmål i staden for å hauste fleire krasj, fordi ein lokalisert feil mot ein samsvarande byggje er det einaste resultatet som flyttar rapporten framover. Viss ingenting kjem tilbake, er reservealternativet ein kontrollert reproduksjon på ekstra maskinvare, aldri på maskinen som andre er avhengige av.