Kernel-Oops bij het starten van de VPN: bewijs dat het waard is te bewaren

De VPN-client starten is een handig tijdstip, geen oorzaak, en dat onderscheid bepaalt wat er daarna gebeurt. Wanneer een kernel-Oops in die buurt optreedt, is de keuze tussen het verzamelen van een bruikbaar foutrapport en het nog vijf keer uitlokken van dezelfde crash op een productiemachine. Bewaar vier dingen voordat u opnieuw opstart: de exacte kernel-build, de eerste fouttracering, de taint-status en een korte beschrijving van al het andere dat in dezelfde minuut veranderde. De rest is interpretatie, en interpretatie kan wachten tot het bewijs op een veilige plek staat.

Leg de eerste fout vast, niet de laatste regel

De eerste Oops in het log is degene die ertoe doet, omdat elke latere fout bijkomende schade kan zijn van een kernel die al niet gezond is. Kopieer de kop samen met de call trace, omdat de kop de foutieve instructie en de registerstatus bevat die het codepad identificeren. Een rapport dat bij de laatste regel begint, is weinig waard voor wie het een week later leest.

Als de machine al opnieuw is opgestart, staat de kernelbuffer van de vorige start vaak nog in het journaal, mits toen permanente opslag was ingeschakeld. Lees die uit het opgeslagen bestand in plaats van de werklast opnieuw te maken, omdat een tweede reproductie kan overschrijven wat u nodig hebt. Waar de machine geen journaal tussen herstarts kan bewaren, is een seriële console of netconsole de enige manier waarop de fout ooit zichtbaar wordt.

Zet de build vast voordat u een symbool leest

Functienamen en offsets betekenen alleen iets ten opzichte van het binaire bestand dat ze heeft geproduceerd, dus noteer de kernel-releasestring en de build-identificatie van de distributie samen. Een symboolbestand uit een andere build wijst met volle overtuiging naar de verkeerde regel, wat erger is dan helemaal geen symbool hebben. Bewaar de versie van het kernelpakket, niet alleen het upstream-nummer, omdat distributies veel terugporten.

Modules buiten de boom verdienen hun eigen regel in het verslag, omdat een getainte kernel beperkt wat een beheerder mag concluderen. Lees de taint-waarde in plaats van die af te leiden uit een modulelijst.

Een taint die niet nul is, is geen beschuldiging en maakt het rapport niet waardeloos. Hij vertelt de lezer welke componenten geladen waren toen de fout optrad, en sommige vlaggen zorgen ervoor dat een rapport eerder door beleid dan door oordeel wordt gedeprioriteerd. Noteer de waarde, de modulenamen en of dezelfde hardware en werklast ooit een kernel zonder hen hebben gedraaid. Juist die laatste vergelijking scheidt een nieuwe regressie van een oude fout.

Scheid een trigger van een defect

Het starten van de tunnel gebruikt meestal een pad dat al bestond: een netwerkstuurprogramma, een wachtrijdiscipline, een offload-functie of een energiestatus. De trigger verklaart wanneer de fout verschijnt, niet welke code fout is, en de trigger als oorzaak behandelen leidt tot een reeks configuratiewijzigingen die niets oplossen.

Een werkende eerdere image is bewijs, geen bewijsvoering. Wijzig bij het vergelijken één component per start, en bewaar de resultaten ergens wat de machine overleeft.

Controleer wat de beheerder echt kan gebruiken

Lees het rapport zoals een vreemde het zou lezen voordat u het verstuurt. Als de configuratie, de exacte volgorde en de build-identiteit aanwezig zijn, en de inloggegevens zijn verwijderd, is het rapport bruikbaar. Als het een schermafbeelding van een stacktrace is, komt het terug met een verzoek om dezelfde informatie. De gids voor het opsporen van kernelbugs beschrijft hoe een bruikbare trace en bijpassende symbolen eruitzien.

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

Elk commando hierboven leest alleen status, en de eerste twee moeten voor de volgende herstart draaien als de machine ze nog kan beantwoorden. Waar het journaal niet persistent is, zijn die twee de enige die ooit weer werken.

Verwijder sleutels, wachtwoorden en ongerelateerd verkeer, maar houd de functienamen en offsets die iemand nodig heeft om de trace te lezen. Stuur het materiaal via het meldpad dat geldt voor de distributie of de kernel, niet via een openbare plak met een hostnaam eraan. Wacht daarna op een vraag in plaats van meer crashes te oogsten, omdat een gelokaliseerde fout tegen een bijpassende build het enige resultaat is dat het rapport vooruit helpt. Als er niets terugkomt, is de terugvaloptie een gecontroleerde reproductie op reservehardware, nooit op de machine waarvan anderen afhankelijk zijn.