Säkerhetskopiera och analysera Linux-kraschdumps med kdump

Vad kdump registrerar vid en kärnkrasch

kdump förbereder en säkerhetskopia av en Linux-kärnans minnesavbildning innan ett systemkrasch inträffar. För detta ändamål reserveras ett minnesområde när den vanliga kärnan startas. I detta område placeras en separat Capture-kärna laddad, som kan startas via kexec vid en lämplig krasch.

Capture-kärnan körs oberoende av den kraschade systemkärnan och får åtkomst till dess minnesavbildning via /proc/vmcore. Den kan spara denna avbildning till en konfigurerad destination. Den sparade filen kallas vanligtvis vmcore; om den innehåller alla ursprungliga minnesområden beror bland annat på vilken filtrering som valts.

Uppgifterna är åtskilda: kdump registrerar och sparar tillståndet, medan programmet krasch en befintlig dump analyseras därefter. På så sätt går det till exempel att undersöka kärnmeddelanden och uppgiftsköer. En dump är en ögonblicksbild och ger inte automatiskt en fullständig bakgrund till felet.

En kernel-oops är inte detsamma som en kernel-panic: En oops kan inträffa utan att systemet omedelbart övergår till en panic. Därför leder inte varje kernelstörning till en kdump-insamling. En core-dump från en applikation avser däremot tillståndet hos en process och är inte en kernel-vmcore.

Denna förberedelse är avgörande för den efterföljande utredningen. Om ingen Capture-kärna var förberedd vid tidpunkten för kraschen eller om ingen avbildning sparades, kan kdump inte rekonstruera det förlorade minnesläget i efterhand. I så fall utgör befintliga loggar och andra diagnostiska data som bevarats efter omstarten utgångspunkten.

Förutsättningar och begränsningar för registreringen

Ta först reda på serverns distribution, version och arkitektur. Paketnamn, tjänstestyrning, startkonfiguration och vilka lagringsmål som stöds beror på dessa faktorer. Använd dokumentationen för just den här plattformen vid installationen, istället för att kombinera kommandon från olika distributioner; även hårdvaran och de installerade drivrutinerna påverkar kraven.

Startparametern crashkernel fastställer Lagringsreservation för kraschregistrering. Detta område är inte tillgängligt för normal drift. Ett fast värde är inte tillförlitligt: Utgå från riktlinjerna för distribution, arkitektur och konkret utrustning och ta hänsyn till lagringsbehovet för inspelningssystemet.

Det räcker inte med det reserverade minnet. Capture-kärnan måste vara laddad och kunna nå det konfigurerade målet. För detta måste de nödvändiga drivrutinerna och komponenterna finnas tillgängliga i dess miljö; vid ett nätverksmål ingår även anslutningen och en nåbar motpart bland förutsättningarna.

Se till att det finns tillräcklig kapacitet på målet för de förväntade avbildningarna och deras lagring. Hur stor en dump blir beror bland annat på lagringsinnehållet och filtreringen. Ett fullt eller oåtkomligt mål kan förhindra säkerhetskopieringen, även om reserveringen är korrekt inställd.

Inte ens en förberedd installation garanterar att dumpen blir användbar. Ett ”Oops” utlöser inte nödvändigtvis ett ”Panic”; vid total strömavbrott kan inte Capture-kärnan fungera längre. På samma sätt kan ett allvarligt hårdvarufel förhindra att den startar eller att avbildningen skrivs. Insamling och mål måste därför betraktas separat från den egentliga orsaken till felet.

Vilka filer som ingår i analysen

För analysen är det inte bara dumpfilen som är viktig. Spara om möjligt även de tillhörande kärnfilerna och loggarna, så att tillståndet vid tidpunkten för kraschen kan jämföras med meddelanden och ändringar. I följande översikt skiljs själva minnesavbildningen från de hjälpfiler som gör det möjligt att utvärdera den.

Det här är särskilt viktigt passande vmlinux: Arkitekturen och den exakta kärnbyggnaden måste stämma överens med den systemkärna som kraschade. Den kärna som körs efter omstarten kan vara en annan. Utmatningen från uname -r på den nystartade servern räcker det därför inte för att välja rätt fil för den gamla dumpen.

Använd dessutom en version av crash som är kompatibel med kärnan och dumpformatet. Om externa eller ytterligare drivrutiner är relevanta, se till att även ha tillhörande modulfiler och felsökningsinformation tillgängliga. Om symboler saknas eller om nödvändiga minnessidor har filtrerats bort kan utvärderingen bli begränsad; sådana luckor ska dokumenteras i rapporten.

En vmcore kan innehålla konfidentiellt innehåll från arbetsminnet. Begränsa därför åtkomsten, skydda överföringen och fastställ tidsfrister för lagring och radering. Innan du vidarebefordrar en dump eller kompletterande loggar till en supporttjänst ska du klargöra vilken godkännande som krävs och vilken omfattning som är tillåten.

Förbereda kdump på servern

Utgångspunkten är serverns distribution, version och arkitektur. Kontrollera i dokumentationen vilka paket som krävs för kdump och för att ladda Capture-kärnan samt hur tjänsten konfigureras. Instruktioner för olika distributioner är inte utbytbara: paketnamn, startkonfiguration och kontrollverktyg kan skilja sig åt.

I förberedelserna ingår att välja rätt Lagringsreservation om startparametern crashkernel. Välj storlek och eventuellt ytterligare inställningar enligt riktlinjerna för den specifika plattformen och hårdvaran. Det reserverade minnet saknas i det normalt körda systemet; en universell storleksangivelse skulle därför vara lika lite till hjälp som en okontrollerad övertagning från en annan server.

Efter den plattformsspecifika startkonfigurationen och en eventuell omstart visar följande läsande shell-kommando parametrarna för den kärna som för närvarande körs. Leta efter följande i utdata: crashkernel. En post visar den angivna inställningen, men bevisar varken att en capture-kärna har laddats eller att säkerhetskopieringen har lyckats.

cat /proc/cmdline

I RHEL 9 kan du dessutom kontrollera statusen med följande kommando i shell. I andra distributioner använder du den kontrollmetod som beskrivs där. Ett positivt Statusmeddelande är en viktig indikation på beredskapen, men ersätter inte en kontrollerad testning av hela säkerhetskedjan.

kdumpctl status

Kontrollera dessutom om det avsedda målet och de drivrutiner som krävs för detta finns tillgängliga i Capture-systemet. Notera de valda inställningarna och tidpunkten för kontrollen, så att du kan utvärdera dem på nytt efter ändringar i kärnan eller infrastrukturen. Du bör kontrollera de specifika inställningarna för den faktiska målplattformen innan du tar dem i bruk.

Välj säkerhetsmål och dumpningsomfång

Das Säkerhetsmål måste vara tillgänglig under insamlingen och ha tillräckligt med ledigt utrymme. En lokal lagringsplats gör att man slipper vara beroende av en nätverksanslutning, men kräver användbart lagringsutrymme på servern. Räkna också med att flera sparade dumpfiler och tillhörande diagnostikfiler kan ta upp utrymme.

RHEL 9 dokumenterar förutom lokala mål även nätverksmål via NFS eller SSH. På så sätt kan filen lagras separat från den berörda servern; för detta krävs att nätverket, motparten och de nödvändiga komponenterna i Capture-systemet fungerar. Kontrollera de respektive begränsningarna för den specifika RHEL-konfigurationen, istället för att anta att tillgängligheten under normal drift är densamma som i inspelningssystemet.

Med makedumpfile kan avbildningen komprimeras och filtreras efter utvalda lagringsområden. Filtrering kan spara lagringsutrymme och överföringsvolym, men tar bort sidor som kan saknas vid en senare utredning. Anpassa därför dumpens omfattning efter den förväntade diagnosen och dokumentera de filter som används; den minsta filen är inte automatiskt den mest användbara.

En vmcore-fil kan innehålla konfidentiellt innehåll från arbetsminnet. Begränsa därför åtkomsten, skydda överföringen och fastställ hur länge filerna ska sparas och när de ska raderas. Innan du vidarebefordrar filen till en supporttjänst ska du klargöra om nödvändigt tillstånd finns; detta gäller även för separat lagrade kopior.

Öppna en befintlig vmcore-fil med crash

För den efterföljande analysen behöver du den befintliga vmcore-filen, som passar den kraschade kärnbyggnaden och arkitekturen vmlinux med felsökningsinformation samt en version av crash som är kompatibel med kärnan och dumpformatet. Kärnan som körs efter en omstart kan vara en annan; enbart versionsinformationen identifierar därför inte den kraschade versionen på ett tillförlitligt sätt.

Följande schematiska kommando ska köras i den vanliga shellen på analyssystemet. Ersätt båda sökvägarna med de faktiska filerna. Kommandot öppnar en befintlig avbildning för analys; det skapar varken en dump eller konfigurerar kdump.

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

Efter en lyckad start kommer du att arbeta med crash-prompt, inte längre i den vanliga shellen. Där visas log de tillgängliga kärnmeddelandena. Börja med att söka efter panikmeddelandet och händelserna kring det; meddelanden kan ge en utgångspunkt, men beskriver inte nödvändigtvis hela orsaken.

Med bt undersöker du stacken för det aktuella analyssammanhanget; bt -a visar stackarna för de aktiva uppgifterna på CPU:erna. Jämför anropskedjorna med meddelandena, istället för att betrakta en enskild ram som bevis på felet. Beroende på dumpens tillstånd och omfattning kan viss information saknas.

I samma kommandorad kan man ps i översikten över uppgifter; kmem -i ger allmän information om minnet. Denna ögonblicksbild i sig bevisar varken att det förekommer ett minnesläckage eller vad som orsakar det. Om en berörd modul ska undersökas närmare kan det dessutom krävas lämpliga modulfiler och felsökningsinformation.

Klassificera stackar och lagringsanvisningar

Om ett panikfel uppstår efter en drivrutinsändring ska du först notera tidpunkten, den kraschade kärnbyggnaden och de berörda modulerna. Jämför dessa uppgifter med ändringsloggen: Uppdaterades endast drivrutinen eller installerades samtidigt en ny kärna? På så sätt kan du avgränsa vilka ändringar som är relevanta för utredningen.

Läs sedan vidare med log de tillgängliga kärnmeddelandena och undersök med bt stacken för det aktuella analyskontexten. bt -a kompletterar översikten över CPU:ernas aktiva uppgifter. Notera inte bara paniktexten utan även de meddelanden som föregick paniken; de kan ge en bakgrund till ett fel som upptäcks senare.

En Drivrutinsram Att det finns något i stacken är en ledtråd, men inget bevis på fel. En tidigare minnesskada kan till exempel först upptäckas i en drivrutinsfunktion. Kontrollera därför om meddelanden, berörda moduler och händelseförloppet stämmer överens innan du fastställer att en ändring är orsaken.

Vid misstankar om lagring lämnar kmem -i En översikt över minnesinformation, i den mån minnesdumpen och verktyget tillhandahåller sådan. Granska dessa värden tillsammans med kärnmeddelandena. Ett enskilt värde bevisar varken ett minnesläckage eller dess orsak; dessutom kan nödvändiga minnessidor saknas på grund av filtrering.

För att kunna avgöra om förbrukningen ökar över tid behöver du kompletterande tidsserier. Vid en separat analys av CPU-belastningen kan CPU-profilering med verktyget Linux Perf hjälpa. Sådana mätningar kompletterar kraschdumpen, men ersätter inte det tillstånd som dokumenterats där vid tidpunkten för kraschen.

Om det inte finns någon användbar vmcore-fil

Efter ett systemhaveri och en efterföljande omstart måste du först ta reda på om det överhuvudtaget har inträffat ett panic-fel och om en vmcore-fil har sparats. En omstart i sig är inte tillräckligt för att bekräfta något av detta. Leta efter meddelanden som tidsmässigt stämmer överens och kontrollera den konfigurerade lagringsplatsen innan du drar slutsatsen att ett visst fel har inträffat bara för att en fil saknas.

Undersök Registreringskedja Separat: Hade en Capture-kärna laddats för den berörda båten, och var händelsen av den typen som kunde utlösa kdump? Inte varje ”oops” leder till en panik. Ett fullständigt strömavbrott eller ett allvarligt hårdvarufel kan dessutom förhindra att Capture-kärnan startar eller skriver data.

Kontrollera därefter säkerhetsmålet: Var det tillgängligt, fanns det tillräckligt med utrymme och innehöll Capture-systemet de drivrutiner och komponenter som behövdes? Vid ett nätverksmål tillkommer anslutningen och motparten som beroenden. Under RHEL kan filen kexec-dmesg.log Ange uppgifter om registreringsfasen, förutsatt att den har skapats och sparats.

Om det inte finns någon användbar dump är tidigare loggfiler eller bestående konsol- och kärnmeddelanden viktiga alternativ. Dessa källor ger dock ingen fullständig minnesavbildning; det förlorade tillståndet går inte att rekonstruera i efterhand med kdump.

Om rapporter eller andra iakttagelser tyder på nätverksproblem kan en kompletterande Analys av SoftIRQ-utnyttjandet i Linux hjälpa till med att klassificera paketbehandlingen. Den besvarar en annan fråga än kontrollen av dumpmålet och bevisar i sig varken en panik eller orsaken till en misslyckad säkerhetskopiering.

Testa datainsamlingen och säkerställa resultaten

Välj dumpens omfattning utifrån den förväntade diagnostiska frågan och de tillgängliga resurserna. Komprimering och filtrering kan spara lagringsutrymme och minska överföringsvolymen, men borttagna minnessidor är då inte längre tillgängliga för senare undersökningar. Dokumentera detta val så att det vid analysen framgår vilka data som eventuellt saknas.

En vmcore-fil kan innehålla konfidentiellt minnesinnehåll. Se därför till att reglera åtkomst, säker överföring och lagringstid samt arkivering av tillhörande felsökningsfiler. Innan du vidarebefordrar filen till en supporttjänst ska du klargöra vilka godkännanden som krävs och hur uppgifterna ska hanteras.

Kontrollera förberedelserna på nytt om kärnan, drivrutinerna, startkonfigurationen eller säkerhetsinfrastrukturen ändras. Detta omfattar den laddade inspelningskärnan och tillgängligheten till det valda målet. Ett positivt statusmeddelande är användbart, men visar i sig inte om en analyserbara dump faktiskt skapas under de aktuella förhållandena.

Varning: Ett kontrollerat end-to-end-test utlöser avsiktligt ett systemkrasch och kan leda till omstarter och dataförlust. Utför det endast i en godkänd testmiljö eller under ett förberett underhållsfönster med säkerhetskopiering. Klargör i förväg ansvarsfördelning, konsekvenser och återstart; ett utlösningskommando anges medvetet inte här.

En talande End-to-end-test Det slutar inte med statuskontrollen: Kontrollera om filen har kommit fram till den avsedda destinationen och om den går att öppna med de filer som hör till den registrerade builden. Dokumentera därefter fynd, saknade data, osäkerheter och nästa kontrollsteg vid serverfelsökningen. Gör tydlig åtskillnad mellan observerade indikationer och ännu obekräftade orsaker.