Linux-crashdumps opslaan en analyseren met kdump

Wat kdump vastlegt bij een kernelcrash

kdump bereidt het maken van een back-up van een Linux-kernelgeheugenafbeelding voor, voordat er een crash optreedt. Hiervoor wordt bij het opstarten van de reguliere kernel een geheugengebied gereserveerd. In dit gebied wordt een afzonderlijke Capture-kernel geladen, dat bij een geschikte crash via kexec kan worden gestart.

De Capture-kernel draait onafhankelijk van de gecrashte systeemkernel en krijgt toegang tot de geheugenafbeelding daarvan via /proc/vmcore. Hij kan deze afbeelding naar een geconfigureerde bestemming schrijven. Het opgeslagen bestand wordt doorgaans vmcore genoemd; of het alle oorspronkelijke geheugengebieden bevat, hangt onder andere af van de gekozen filtering.

De taken zijn gescheiden: kdump registreert en legt de toestand vast, terwijl het programma crash een bestaande dump vervolgens geanalyseerd. Hiermee kunnen bijvoorbeeld kernelmeldingen en takenstapels worden onderzocht. Een dump is daarbij een momentopname en geeft niet automatisch de volledige voorgeschiedenis van de fout weer.

Een kernel-oops is niet hetzelfde als een kernel-panic: een oops kan optreden zonder dat het systeem onmiddellijk in een panic terechtkomt. Daarom leidt niet elke kernelstoring tot een kdump-opname. Een core-dump van een toepassing heeft daarentegen betrekking op de toestand van een proces en is geen kernel-vmcore.

Deze voorbereiding is cruciaal voor het onderzoek achteraf. Als er op het moment van de crash geen capture-kernel was voorbereid of als er geen image is opgeslagen, kan kdump de verloren gegane geheugentoestand later niet reconstrueren. In dat geval vormen de beschikbare logbestanden en andere diagnosegegevens die bij het opnieuw opstarten bewaard zijn gebleven het uitgangspunt.

Voorwaarden en beperkingen van de registratie

Bepaal eerst de distributie, versie en architectuur van de server. Hiervan zijn de pakketnamen, het beheer van de diensten, de opstartconfiguratie en de ondersteunde opslagdoelen afhankelijk. Gebruik voor de installatie de documentatie van precies dit platform, in plaats van commando’s van verschillende distributies te combineren; ook de hardware en de geïnstalleerde stuurprogramma’s zijn van invloed op de vereisten.

De opstartparameter crashkernel bepaalt de Reservering van opslagruimte voor crashregistratie. Dit gebied is niet beschikbaar voor normaal gebruik. Een vaste grootte is niet betrouwbaar: houd je aan de richtlijnen voor distributie, architectuur en concrete uitrusting en houd rekening met de opslagbehoefte van het opnamesysteem.

Het gereserveerde geheugen alleen is niet voldoende. De Capture-kernel moet geladen zijn en de geconfigureerde bestemming moeten kunnen bereiken. Hiervoor moeten de benodigde stuurprogramma’s en componenten in de omgeving beschikbaar zijn; bij een netwerkbestemming behoren ook de verbinding en de bereikbare tegenpartij tot de vereisten.

Zorg ervoor dat er op de bestemming voldoende capaciteit is voor de verwachte afbeeldingen en de opslag daarvan. Hoe groot een dump wordt, hangt onder andere af van de inhoud van het geheugen en van de filtering. Een volle of onbereikbare bestemming kan de back-up verhinderen, zelfs als de reservering correct is ingesteld.

Zelfs een voorbereide installatie biedt geen garantie voor een bruikbare dump. Een ‘oops’ leidt niet noodzakelijkerwijs tot een ‘panic’; bij een volledige stroomuitval kan de capture-kernel niet meer functioneren. Ook kan een ernstige hardwarefout het opstarten of het schrijven van de image verhinderen. De vastlegging en de oorzaak moeten daarom los van de daadwerkelijke foutoorzaak worden bekeken.

Welke bestanden tellen mee voor de analyse

Voor het onderzoek is niet alleen het dumpbestand van belang. Bewaar indien mogelijk ook de bijbehorende kernelbestanden en logbestanden, zodat de toestand op het moment van de crash kan worden vergeleken met meldingen en wijzigingen. In het volgende overzicht wordt het eigenlijke geheugenafbeeld gescheiden van de hulpbestanden die de analyse ervan mogelijk maken.

Dat is bijzonder belangrijk geschikte vmlinux: De architectuur en de exacte kernelbuild moeten overeenkomen met die van de gecrashte systeemkernel. De kernel die na het herstarten draait, kan een andere zijn. De uitvoer van uname -r op de opnieuw opgestarte server is daarom niet voldoende om het juiste bestand voor de oude dump te selecteren.

Gebruik bovendien een versie van crash die compatibel is met de kernel en het dumpformaat. Als er externe of aanvullende stuurprogramma’s van belang zijn, zorg dan ook dat je de bijbehorende modulebestanden en debug-informatie bij de hand hebt. Als er symbolen ontbreken of als benodigde geheugenpagina’s zijn weggefilterd, kan de analyse beperkt zijn; dergelijke hiaten moeten in de documentatie van de bevindingen worden vermeld.

Een vmcore kan vertrouwelijke gegevens uit het werkgeheugen bevatten. Beperk daarom de toegang, beveilig de overdracht en stel bewaar- en verwijderingstermijnen vast. Voordat je een dump of aanvullende logbestanden doorgeeft aan een ondersteuningsdienst, moet je nagaan of hiervoor toestemming nodig is en wat de toegestane omvang is.

kdump op de server voorbereiden

Het uitgangspunt is de distributie, versie en architectuur van de server. Kijk in de documentatie welke pakketten nodig zijn voor kdump en het laden van de capture-kernel, en hoe de dienst moet worden ingesteld. Handleidingen voor verschillende distributies zijn niet zomaar onderling uitwisselbaar: pakketnamen, opstartconfiguratie en controletools kunnen verschillen.

Bij de voorbereiding hoort de juiste Reservering van opslagruimte via de opstartparameter crashkernel. Kies de grootte en eventueel andere instellingen volgens de specificaties voor het betreffende platform en de betreffende hardware. Het gereserveerde geheugen komt ten koste van het normaal draaiende systeem; een algemene grootte-aanduiding zou daarom evenmin nuttig zijn als het klakkeloos overnemen van de instellingen van een andere server.

Na de platformspecifieke opstartconfiguratie en een eventueel noodzakelijke herstart geeft het volgende shell-commando de parameters van de momenteel actieve kernel weer. Zoek in de uitvoer naar crashkernel. Een vermelding geeft de doorgegeven instelling weer, maar bewijst noch dat er een capture-kernel is geladen, noch dat er een back-up is gemaakt.

cat /proc/cmdline

Onder RHEL 9 kun je de status bovendien opvragen met de volgende opdracht in de shell. Op andere distributies volg je de daar beschreven controleprocedure. Een positieve Statusmelding is een belangrijke aanwijzing voor de bereidheid, maar vervangt geen gecontroleerde test van het gehele beveiligingstraject.

kdumpctl status

Controleer bovendien of het beoogde doel en de daarvoor benodigde stuurprogramma’s beschikbaar zijn in het opnamesysteem. Noteer de gekozen instellingen en het tijdstip van de controle, zodat je deze na wijzigingen in de kernel of de infrastructuur opnieuw kunt beoordelen. Controleer concrete instellingen vóór de implementatie op het daadwerkelijk gebruikte doelplatform.

Beveiligingsdoel en dumpomvang selecteren

De Beveiligingsdoelstelling moet tijdens het vastleggen bereikbaar zijn en voldoende vrije ruimte bieden. Een lokale bestemming voorkomt dat je afhankelijk bent van een netwerkverbinding, maar vereist wel bruikbare opslagruimte op de server. Houd er ook rekening mee dat meerdere opgeslagen dumps en bijbehorende diagnosebestanden ruimte in beslag kunnen nemen.

RHEL 9 documenteert naast lokale doelen ook netwerkdoelen via NFS of SSH. Hierdoor kan het bestand los van de betreffende server worden opgeslagen; hiervoor moeten het netwerk, de tegenpartij en de benodigde componenten in het capture-systeem goed functioneren. Controleer de betreffende beperkingen van de specifieke RHEL-configuratie, in plaats van de bereikbaarheid tijdens normaal bedrijf gelijk te stellen aan die in het capture-systeem.

Met makedumpfile kan de afbeelding worden gecomprimeerd en op geselecteerde geheugengebieden worden gefilterd. Filteren kan opslagruimte en dataverkeer besparen, maar verwijdert daarbij pagina’s die later bij het onderzoeken van een probleem wellicht ontbreken. Stem de omvang van de dump daarom af op de verwachte diagnose en documenteer de gebruikte filters; het kleinste bestand is niet automatisch het nuttigste.

Een vmcore kan vertrouwelijke gegevens uit het werkgeheugen bevatten. Beperk daarom de toegang, beveilig de overdracht en leg vast hoe lang de bestanden worden bewaard en wanneer ze worden verwijderd. Voordat je gegevens doorgeeft aan een ondersteuningsdienst, moet je de benodigde toestemming verkrijgen; dit geldt ook voor afzonderlijk opgeslagen kopieën.

Een bestaande vmcore openen met crash

Voor de analyse achteraf heb je het beschikbare vmcore-bestand nodig, dat overeenkomt met de gecrashte kernel-build en de architectuur vmlinux met foutopsporingsinformatie en een versie van crash die compatibel is met de kernel en het dumpformaat. De kernel die na een herstart draait, kan een andere zijn; de versie-informatie alleen is daarom geen betrouwbare manier om de gecrashte build te identificeren.

Het volgende schematische commando hoort thuis in de normale shell op het analysesysteem. Vervang beide paden door de daadwerkelijk aanwezige bestanden. Het commando opent een bestaande dump voor analyse; het maakt geen dump aan en stelt ook geen kdump in.

crash /pfad/zum/passenden/vmlinux /pfad/zum/vmcore

Na een succesvolle start ga je aan de slag met crash-prompt, niet meer in de normale shell. Daar wordt log de beschikbare kernelmeldingen. Zoek eerst naar de panic-melding en de gebeurtenissen rond dat tijdstip; meldingen kunnen een aanknopingspunt bieden, maar geven niet per se de volledige oorzaak weer.

Met bt onderzoek je de stack van de huidige analysecontext; bt -a toont de stacks van de actieve taken op de CPU's. Vergelijk de aanroepketens met de meldingen, in plaats van één enkel frame als bewijs van de oorzaak te beschouwen. Afhankelijk van de toestand en de omvang van de dump kan er informatie ontbreken.

In dezelfde prompt helpt ps in het overzicht van taken; kmem -i geeft algemene informatie over het geheugen weer. Dit momentopname op zich bewijst noch het bestaan van een geheugenlek, noch wat de oorzaak ervan is. Als een betrokken module nader moet worden onderzocht, kunnen daarnaast de bijbehorende modulebestanden en debug-informatie nodig zijn.

Stacks en opslagaanwijzingen indelen

Als er na een wijziging in de driver een panic optreedt, noteer dan eerst het tijdstip, de kernel-build die is gecrasht en de betrokken modules. Vergelijk deze gegevens met het wijzigingslogboek: is alleen het stuurprogramma bijgewerkt of is er tegelijkertijd een nieuwe kernel geïnstalleerd? Zo kun je vaststellen welke wijzigingen relevant zijn voor het onderzoek.

Lees daarna verder met log de beschikbare kernelmeldingen en onderzoek deze met bt de stack van de huidige analysecontext. bt -a vult het overzicht van de actieve taken van de CPU's aan. Noteer naast de panic-tekst ook de meldingen die aan de panic voorafgingen; deze kunnen de context van een later zichtbare fout verduidelijken.

A Aandrijfframe De stacktrace biedt een aanknopingspunt, maar is geen bewijs van schuld. Zo kan een eerdere beschadiging van het geheugen pas in een stuurprogrammafunctie aan het licht komen. Controleer daarom of de meldingen, de betrokken modules en het verloop met elkaar overeenkomen, voordat je een wijziging als oorzaak vaststelt.

Bij een vermoeden van opslag levert kmem -i een overzicht van geheugeninformatie, voor zover de dump en de tool deze beschikbaar stellen. Bekijk deze waarden in combinatie met de kernelberichten. Een enkele waarde wijst noch op een geheugenlek, noch op de oorzaak ervan; bovendien kunnen door filtering de benodigde geheugenpagina’s ontbreken.

Om te bepalen of het verbruik zich in de loop van de tijd opbouwt, heb je aanvullende tijdreeksen nodig. Bij een afzonderlijke analyse van de CPU-belasting kan CPU-profilering met de Linux Perf-tool helpen. Dergelijke metingen vormen een aanvulling op de crash-dump, maar vervangen niet de toestand die daarin is vastgelegd op het moment van de crash.

Als er geen bruikbaar vmcore-bestand beschikbaar is

Na een vastloper en een daaropvolgende herstart moet je eerst nagaan of er überhaupt een panic heeft plaatsgevonden en of er een vmcore-bestand is opgeslagen. Een herstart op zich is geen bewijs voor beide. Zoek naar meldingen die qua tijd overeenkomen en controleer de geconfigureerde opslaglocatie, voordat je uit het ontbreken van een bestand concludeert dat er sprake is van een bepaalde fout.

Onderzoek de Registratieketen Afzonderlijk: Was er voor de betreffende boot een capture-kernel geladen en was de gebeurtenis geschikt om kdump te activeren? Niet elke oops leidt tot een panic. Een volledige stroomuitval of een ernstige hardwarefout kan er bovendien voor zorgen dat de capture-kernel niet opstart of geen gegevens schrijft.

Controleer vervolgens de back-upbestemming: was deze bereikbaar, was er voldoende ruimte beschikbaar en bevatte het Capture-systeem de benodigde stuurprogramma’s en componenten? Bij een netwerkbestemming komen daar nog de verbinding en het tegenstation als afhankelijkheden bij. Onder RHEL kan het bestand kexec-dmesg.log Vermeldingen over de registratiefase, voor zover deze is opgesteld en opgeslagen.

Als er geen bruikbare dump beschikbaar is, vormen eerdere logbestanden of permanente console- en kernelmeldingen belangrijke alternatieven. Deze bronnen leveren echter geen volledige geheugenafbeelding op; de verloren toestand kan achteraf niet met kdump worden gereconstrueerd.

Als meldingen of andere waarnemingen wijzen op netwerkproblemen, kan een aanvullende Analyse van het gebruik van SoftIRQ’s in Linux helpt bij het indelen van de pakketverwerking. Het geeft antwoord op een andere vraag dan de controle van de dumpbestemming en bewijst op zichzelf noch een paniek, noch de oorzaak van een mislukte back-up.

De registratie testen en de resultaten vastleggen

Kies de omvang van de dump op basis van de verwachte diagnostische vraag en de beschikbare middelen. Compressie en filtering kunnen opslagruimte en dataverkeer besparen; verwijderde geheugenpagina’s zijn dan echter niet meer beschikbaar voor later onderzoek. Leg deze beslissing vast, zodat bij de analyse duidelijk blijft welke gegevens mogelijk ontbreken.

Een vmcore kan vertrouwelijke gegevens bevatten. Zorg daarom voor de juiste toegangsregels, beveiligde overdracht en bewaartermijn, evenals de opslag van bijbehorende debugbestanden. Voordat je de gegevens doorgeeft aan een ondersteuningsdienst, moet je nagaan of er toestemming voor is en hoe er met de gegevens moet worden omgegaan.

Controleer de voorbereiding opnieuw als de kernel, stuurprogramma’s, opstartconfiguratie of back-upinfrastructuur veranderen. Hieronder vallen de geladen capture-kernel en de bereikbaarheid van het gekozen doel. Een positieve statusmelding is nuttig, maar geeft op zichzelf niet aan of er onder de huidige omstandigheden daadwerkelijk een analyseerbare dump wordt gegenereerd.

Waarschuwing: Een gecontroleerde end-to-end-test veroorzaakt opzettelijk een systeemcrash en kan leiden tot herstarts en gegevensverlies. Voer deze test alleen uit in een goedgekeurde testomgeving of tijdens een vooraf gepland onderhoudsvenster met een back-up van de gegevens. Leg vooraf de verantwoordelijkheden, gevolgen en herstelprocedures vast; er wordt hiervoor bewust geen opdracht gegeven om de crash te activeren.

Een veelzeggende End-to-end-test Het houdt niet op bij de statuscontrole: controleer of het bestand op de beoogde bestemming is aangekomen en of het kan worden geopend met de bestanden die bij de geregistreerde build horen. Noteer vervolgens bij het serverdebuggen de bevindingen, ontbrekende gegevens, onzekerheden en de volgende controlestappen. Maak daarbij een duidelijk onderscheid tussen waargenomen aanwijzingen en nog onbevestigde oorzaken.