Sikkerhedskopiering og analyse af Linux-crash-dumps med kdump

Hvad kdump registrerer ved et kernel-nedbrud

kdump forbereder sikkerhedskopieringen af et Linux-kernel-hukommelsesbillede, inden der opstår et nedbrud. Til dette formål reserveres der et hukommelsesområde ved opstart af den almindelige kernel. I dette område oprettes en separat Capture-kernen indlæst, som kan startes via kexec i tilfælde af en passende nedbrudssituation.

Capture-kernen kører uafhængigt af den nedbrudte systemkerne og får adgang til dens hukommelsesafbildning via /proc/vmcore. Han kan skrive dette billede til en konfigureret destination. Den gemte fil kaldes normalt vmcore; om den indeholder alle de oprindelige hukommelsesområder, afhænger blandt andet af den valgte filtrering.

Opgaverne er adskilte: kdump registrerer og gemmer tilstanden, mens programmet crash derefter analyseres en eksisterende dump. På den måde kan man f.eks. undersøge kernefejlmeddelelser og opgavestakke. En dump er et øjebliksbillede og giver ikke automatisk den fulde forhistorie bag fejlen.

En kernel-oops er ikke det samme som en kernel-panic: En oops kan opstå, uden at systemet straks går i panic. Derfor fører ikke enhver kernel-fejl til en kdump-registrering. En core-dump fra et program vedrører derimod en process tilstand og er ikke en kernel-vmcore.

Denne forberedelse er afgørende for den efterfølgende undersøgelse. Hvis der ikke var forberedt en capture-kernel på tidspunktet for nedbruddet, eller hvis der ikke blev taget en sikkerhedskopi af billedet, kan kdump ikke senere rekonstruere den tabte hukommelsestilstand. I så fald udgør de eksisterende logfiler og andre diagnosedata, der er bevaret efter genstarten, udgangspunktet.

Forudsætninger og begrænsninger for registreringen

Find først ud af serverens distribution, version og arkitektur. Pakkenavne, tjenestestyring, opstartskonfiguration og understøttede lagringsmål afhænger nemlig af disse faktorer. Brug dokumentationen for netop denne platform til opsætningen i stedet for at kombinere kommandoer fra forskellige distributioner; også hardware og installerede drivere har indflydelse på kravene.

Boot-parameteren crashkernel fastsætter Reservering af lagerplads til registrering af systemnedbrud. Dette område er ikke tilgængeligt til normal drift. En fast størrelse er ikke pålidelig: Hold dig til retningslinjerne for distribution, arkitektur og konkret udstyr, og tag højde for capture-systemets lagerbehov.

Den reserverede hukommelse er ikke nok i sig selv. Capture-kernen skal være indlæst og kunne nå den konfigurerede destination. Til dette skal de nødvendige drivere og komponenter være tilgængelige i dens miljø; ved en netværksdestination er forbindelsen og den tilgængelige modpart også en forudsætning.

Sørg for, at der er tilstrækkelig kapacitet på målstedet til de forventede afbildninger og opbevaringen heraf. Størrelsen på en dump afhænger blandt andet af lagerindholdet og filtreringen. Et fuldt eller utilgængeligt målsted kan forhindre sikkerhedskopieringen, selvom reservationen er indstillet korrekt.

Selv en forberedt installation er ingen garanti for en brugbar dump. En »Oops« udløser ikke nødvendigvis en »Panic«; ved fuldstændigt strømsvigt kan capture-kernen ikke længere fungere. Ligeledes kan en alvorlig hardwarefejl forhindre opstart eller skrivning af billedet. Optagelse og årsag skal derfor betragtes separat fra den egentlige fejlårsag.

Hvilke filer indgår i analysen

Det er ikke kun dumpfilen, der er vigtig for undersøgelsen. Gem om muligt også de tilhørende kernel-filer og logfiler, så tilstanden på tidspunktet for nedbruddet kan sammenlignes med meddelelser og ændringer. I den følgende oversigt skelnes der mellem selve hukommelsesafbildningen og de hjælpefiler, der gør det muligt at analysere den.

Det er særligt vigtigt, at passende vmlinux: Arkitekturen og den nøjagtige kernel-build skal stemme overens med den systemkernel, der gik ned. Den kernel, der kører efter genstart, kan være en anden. Udskriften fra uname -r på den nyligt opstartede server er det derfor ikke nok til at vælge den rigtige fil til den gamle dump.

Brug desuden en version af crash, der er kompatibel med kernen og dumpformatet. Hvis der er eksterne eller yderligere drivere involveret, skal du også have de tilhørende modulfiler og fejlfindingsoplysninger klar. Hvis der mangler symboler, eller hvis nødvendige hukommelsessider er blevet filtreret fra, kan analysen være begrænset; sådanne mangler skal angives i dokumentationen af resultaterne.

En vmcore kan indeholde fortrolige oplysninger fra arbejdsminnet. Begræns derfor adgangen, beskyt overførslen, og fastlæg opbevarings- og sletningsfrister. Inden du videregiver en dump eller supplerende logfiler til en supporttjeneste, skal du afklare den nødvendige godkendelse og det tilladte omfang.

Forberedelse af kdump på serveren

Udgangspunktet er serverens distribution, version og arkitektur. Tjek i deres dokumentation, hvilke pakker der kræves til kdump og indlæsning af capture-kernen, og hvordan tjenesten konfigureres. Vejledninger til forskellige distributioner kan ikke bruges i flæng: Pakkenavne, opstartskonfiguration og kontrolværktøjer kan variere.

Som en del af forberedelsen skal man sørge for den rette Reservering af lagerplads om boot-parameteren crashkernel. Vælg størrelse og eventuelt yderligere indstillinger i henhold til retningslinjerne for den konkrete platform og hardware. Den reserverede hukommelse mangler i det normalt kørende system; en universel størrelsesangivelse ville derfor være lige så lidt nyttig som en ukontrolleret overtagelse fra en anden server.

Efter den platformspecifikke boot-konfiguration og en eventuel genstart viser følgende shell-kommando i læsemodus parametrene for den aktuelt kørende kerne. Se efter følgende i udskriften: crashkernel. En post viser den overførte indstilling, men beviser hverken, at en capture-kernel er indlæst, eller at sikkerhedskopieringen er lykkedes.

cat /proc/cmdline

I RHEL 9 kan du desuden tjekke status med følgende kommando i shellen. I andre distributioner skal du følge den fremgangsmåde, der er beskrevet der. Et positivt Statusmeddelelse er et vigtigt tegn på beredskab, men erstatter ikke en kontrolleret gennemgang af hele sikkerhedsprocessen.

kdumpctl status

Kontroller desuden, om den påtænkte destination og de nødvendige drivere er tilgængelige i Capture-systemet. Notér de valgte indstillinger og tidspunktet for kontrollen, så du kan vurdere dem på ny efter ændringer i kernen eller infrastrukturen. Du bør kontrollere de konkrete indstillinger for den faktisk anvendte målplatform, inden du tager dem i brug.

Vælg sikkerhedsmål og dumpomfang

Das Sikkerhedsmål skal være tilgængelig under indsamlingen og have tilstrækkelig ledig plads. En lokal destination undgår afhængighed af en netværksforbindelse, men kræver dog ledig lagerplads på serveren. Husk også, at flere gemte dumps og tilhørende diagnostiske filer kan optage plads.

RHEL 9 dokumenterer ud over lokale mål også netværksmål via NFS eller SSH. Dette gør det muligt at gemme filen separat fra den pågældende server; for at dette skal fungere, skal netværket, modparten og de nødvendige komponenter i Capture-systemet fungere. Kontroller de respektive begrænsninger for den konkrete RHEL-konfiguration, i stedet for at antage, at tilgængeligheden under normal drift svarer til tilgængeligheden i Capture-systemet.

Med makedumpfile kan billedet komprimeres og filtreres efter udvalgte hukommelsesområder. Filtrering kan spare lagerplads og overførselsvolumen, men fjerner sider, der kan mangle i forbindelse med en senere undersøgelse. Tilpas derfor dumpens omfang til den forventede diagnose, og dokumenter de anvendte filtre; den mindste fil er ikke nødvendigvis den mest nyttige.

En vmcore kan indeholde fortrolige oplysninger fra arbejdshukommelsen. Begræns derfor adgangen, beskyt overførslen, og fastlæg, hvor længe filerne skal opbevares, og hvornår de skal slettes. Inden du videregiver filerne til en supporttjeneste, skal du sikre dig, at der foreligger den nødvendige godkendelse; dette gælder også for separat gemte kopier.

Åbn en eksisterende vmcore-fil med crash

Til den efterfølgende analyse skal du bruge den eksisterende vmcore, som passer til den nedbrudte kernel-build og arkitekturen vmlinux med fejlfindingsoplysninger samt en version af crash, der er kompatibel med kernen og dump-formatet. Den kerne, der kører efter en genstart, kan være en anden; dens versionsangivelse alene identificerer derfor ikke pålideligt den nedbrudte build.

Følgende skematiske kommando skal indtastes i den normale shell på analysesystemet. Erstat begge stier med de faktisk eksisterende filer. Kommandoen åbner et eksisterende billede til analyse; den genererer hverken en dump eller konfigurerer kdump.

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

Efter en vellykket start kommer du til at arbejde med crash-prompt, ikke længere i den normale shell. Der viser log de tilgængelige kernelmeddelelser. Søg først efter panikmeddelelsen og de meddelelser, der ligger tæt op ad den tidsmæssigt; meddelelser kan give et udgangspunkt, men beskriver ikke nødvendigvis den fulde årsag.

Med bt undersøger du stakken i den aktuelle analysekontest; bt -a viser stakkerne for de aktive opgaver på CPU’erne. Sammenlign opkaldskæderne med fejlmeddelelserne i stedet for at betragte en enkelt frame som bevis på fejlen. Afhængigt af dumpens tilstand og omfang kan der mangle oplysninger.

I den samme prompt hjælper ps i oversigten over opgaver; kmem -i giver generelle oplysninger om hukommelsen. Dette øjebliksbillede i sig selv beviser hverken, at der er et hukommelseslæk, eller hvad der forårsager det. Hvis et af de involverede moduler skal undersøges nærmere, kan det være nødvendigt at indhente de relevante modulfiler og fejlfindingsoplysninger.

Sortering af stakke og hukommelseshenvisninger

Hvis der opstår en panik efter en driverændring, skal du først notere tidspunktet, den nedbrudte kernel-build og de involverede moduler. Sammenlign disse oplysninger med ændringsloggen: Er det kun driveren, der er blevet opdateret, eller er der samtidig blevet installeret en ny kerne? På den måde kan du afgrænse, hvilke ændringer der er relevante for undersøgelsen.

Læs derefter videre med log de tilgængelige kernelmeddelelser og undersøg dem med bt stakken for den aktuelle analysekontest. bt -a supplerer oversigten over CPU'ernes aktive opgaver. Notér ikke kun panikteksten, men også de meddelelser, der gik forud for panikken; de kan give en sammenhæng til en fejl, der senere bliver synlig.

En Driverramme I stakken er der et udgangspunkt, men ikke et bevis på skyld. For eksempel kan en tidligere hukommelsesskade først blive opdaget i en driverfunktion. Kontroller derfor, om meddelelser, de involverede moduler og forløbet stemmer overens, før du fastslår, at en ændring er årsagen.

Ved mistanke om lagring leverer kmem -i En oversigt over hukommelsesoplysninger, i det omfang dumpen og værktøjet stiller dem til rådighed. Betragt disse værdier sammen med kernebeskederne. En enkelt værdi beviser hverken et hukommelseslæk eller dets årsag; desuden kan nødvendige hukommelsessider mangle på grund af filtrering.

For at kunne afgøre, om forbruget stiger over tid, har du brug for supplerende tidsserier. Ved en separat undersøgelse af CPU-belastningen kan CPU-profilering med Linux Perf-værktøjet hjælpe. Sådanne målinger supplerer crash-dumpen, men erstatter ikke den tilstand, der er registreret i den på tidspunktet for nedbruddet.

Hvis der ikke findes en brugbar vmcore-fil

Efter et nedbrud og en efterfølgende genstart skal du først afklare, om der overhovedet er opstået en panic, og om der er blevet gemt en vmcore-fil. En genstart i sig selv er ikke bevis for nogen af delene. Søg efter meddelelser, der passer tidsmæssigt, og tjek den konfigurerede gemmested, før du ud fra fraværet af en fil konkluderer, at der er tale om en bestemt fejl.

Undersøg Registreringskæde Separat: Var der indlæst en capture-kernel på den berørte båd, og var hændelsen af en sådan art, at den kunne udløse kdump? Ikke alle »oops« fører til en »panic«. Et fuldstændigt strømsvigt eller en alvorlig hardwarefejl kan desuden forhindre, at capture-kernelen starter eller skriver data.

Kontroller derefter sikkerhedskopieringsmålet: Var det tilgængeligt, var der tilstrækkelig plads til rådighed, og indeholdt Capture-systemet de nødvendige drivere og komponenter? Ved et netværksmål kommer forbindelsen og modparten oveni som afhængigheder. Under RHEL kan filen kexec-dmesg.log Angiv oplysninger om registreringsfasen, forudsat at den er blevet udarbejdet og gemt.

Hvis der ikke findes et brugbart dump, er tidligere logfiler eller vedvarende konsol- og kernelmeldinger vigtige alternativer. Disse kilder leverer dog ikke et fuldstændigt hukommelsesbillede; den tabte tilstand kan ikke rekonstrueres efterfølgende med kdump.

Hvis der er tegn på netværksproblemer i form af fejlmeldinger eller andre observationer, kan en supplerende Analyse af Linux-SoftIRQ-udnyttelsen hjælper med at klassificere pakkehåndteringen. Den besvarer et andet spørgsmål end kontrollen af dump-målet og beviser hverken en panik eller årsagen til en mislykket sikkerhedskopiering.

Test registreringen og bekræft resultaterne

Vælg omfanget af dumpen ud fra det forventede diagnosespørgsmål og de tilgængelige ressourcer. Komprimering og filtrering kan spare lagerplads og reducere overførselsmængden; fjernede lagersider vil dog ikke længere være tilgængelige til senere undersøgelser. Dokumenter denne beslutning, så det ved analysen fremgår, hvilke data der muligvis mangler.

En vmcore kan indeholde fortrolige hukommelsesindhold. Du skal derfor regulere adgangen, sikre en beskyttet overførsel og fastlægge opbevaringsperioden samt arkiveringen af relevante fejlfindingsfiler. Inden du videregiver filen til en supporttjeneste, skal du afklare den nødvendige godkendelse og den planlagte håndtering af dataene.

Kontroller forberedelserne igen, hvis der sker ændringer i kernen, driverne, opstartskonfigurationen eller sikkerhedsinfrastrukturen. Dette omfatter den indlæste capture-kerne og tilgængeligheden af det valgte mål. En positiv statusmeddelelse er nyttig, men viser i sig selv ikke, om der under de aktuelle forhold rent faktisk opstår en dump, der kan analyseres.

Advarsel: En kontrolleret end-to-end-test udløser bevidst et systemnedbrud og kan medføre genstart og datatab. Udfør den kun i et godkendt testmiljø eller i et forberedt vedligeholdelsesvindue med sikkerhedskopiering af data. Afklar på forhånd ansvarsforhold, konsekvenser og genopstart; der er bevidst ikke angivet en udløsningskommando hertil.

En meningsfuld End-to-end-test Det slutter ikke med statuskontrollen: Kontroller, om filen er ankommet til den tilsigtede destination, og om den kan åbnes sammen med de filer, der hører til den registrerede build. Notér derefter fund, manglende data, usikkerheder og de næste kontroltrin under serverdebugging. Sørg for at skelne klart mellem observerede tegn og endnu ubekræftede årsager.