Kernel-Oops när VPN startar: bevis som är värda att spara

Att starta VPN-klienten är en praktisk tidsstämpel, inte en orsak, och den skillnaden avgör vad som händer härnäst. När en kernel-Oops inträffar nära det ögonblicket står valet mellan att samla in en användbar felrapport och att framkalla samma krasch fem gånger till på en produktionsmaskin. Spara fyra saker före omstarten: det exakta kernel-bygget, det första felspåret, taint-tillståndet och en kort beskrivning av allt annat som ändrades samma minut. Resten är tolkning, och tolkningen kan vänta tills bevisen finns på ett säkert ställe.

Fånga det första felet, inte den sista raden

Den första Oops i loggen är den som spelar roll, eftersom varje senare fel kan vara följdskada från en kärna som redan inte är frisk. Kopiera huvudet tillsammans med call trace, eftersom huvudet bär instruktionen som misslyckades och registertillståndet som identifierar kodvägen. En rapport som börjar vid den sista raden är väldigt lite värd för den som läser den en vecka senare.

Om maskinen redan har startat om finns kärnbufferten från föregående start ofta kvar i journalen, förutsatt att beständig lagring var aktiverad då. Läs den från den sparade filen istället för att återskapa arbetsbelastningen, eftersom en andra reproduktion kan skriva över det du behöver. Där maskinen inte kan hålla en journal mellan omstarter är en seriell konsol eller netconsole det enda sättet som felet någonsin blir synligt.

Lås bygget innan du läser någon symbol

Funktionsnamn och offset betyder bara något mot binärfilen som producerade dem, så notera kernel-utgivningssträngen och distributionens byggidentifierare tillsammans. En symbolfil från ett annat bygge pekar på fel rad med full övertygelse, vilket är värre än att inte ha någon symbol alls. Behåll versionen av kernel-paketet, inte bara upstream-numret, eftersom distributioner bakportar mycket.

Moduler utanför trädet förtjänar sin egen rad i protokollet, eftersom en taintad kärna begränsar vad en underhållare får dra för slutsatser. Läs taint-värdet istället för att härleda det från en modullista.

En taint som inte är noll är inte en anklagelse och gör inte rapporten värdelös. Den berättar för läsaren vilka komponenter som var laddade när felet inträffade, och vissa flaggor gör att en rapport nedprioriteras av policy snarare än av bedömning. Notera värdet, modulnamnen och om samma hårdvara och arbetsbelastning någonsin körde en kärna utan dem. Just den sista jämförelsen skiljer en ny regression från ett gammalt fel.

Skilj en utlösare från en defekt

Att starta tunneln använder normalt en väg som redan fanns: en nätverksdrivrutin, en ködisciplin, en offload-funktion eller ett energitillstånd. Utlösaren förklarar när felet visas, inte vilken kod som är fel, och att behandla utlösaren som orsaken leder till en rad konfigurationsändringar som inte åtgärdar något.

En fungerande tidigare avbildning är bevis, inte bevisföring. Vid jämförelse, ändra en komponent per start och förvara resultaten någonstans som överlever maskinen.

Kontrollera vad underhållaren faktiskt kan använda

Läs rapporten som en främling skulle läsa den innan du skickar den. Om konfigurationen, den exakta sekvensen och byggidentiteten finns där, och inloggningsuppgifterna är borta, är rapporten användbar. Om det är en skärmbild av ett stack trace kommer den tillbaka med en begäran om samma information. Guiden för att söka kärnbuggar beskriver hur ett användbart spår och matchande 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:'

Varje kommando ovan läser bara tillstånd, och de två första bör köras före nästa omstart om maskinen fortfarande kan svara på dem. Där journalen inte är beständig är de två de enda som någonsin kommer att fungera igen.

Ta bort nycklar, lösenord och orelaterad trafik, men behåll funktionsnamnen och offseten som någon behöver för att läsa spåret. Skicka materialet via den rapporteringsväg som gäller för distributionen eller kärnan, inte en offentlig inklistring med ett värdnamn bifogat. Vänta sedan på en fråga istället för att skörda fler krascher, eftersom ett lokaliserat fel mot ett matchande bygge är det enda resultatet som flyttar rapporten framåt. Om inget kommer tillbaka är reservlösningen en kontrollerad reproduktion på extra hårdvara, aldrig på maskinen som andra människor är beroende av.