Sådan bruger du Crash og Kdump til Linux: En komplet og praktisk guide

Når systemet Linux oplever en kernel panic-hængning (se Forskelle mellem kernelpanik og systemnedbrud), er det eneste pålidelige spor normalt en core dump. Konfigurer kdump og analyser vmcore med crash Det kan betyde forskellen mellem at gætte og at præcist diagnosticere, hvad der skete, især hvis loggen ikke efterlader spor.

I denne praktiske guide har jeg samlet det essentielle fra de bedste tekniske kilder om emnet for at give dig en klar køreplan: Hvad er kdump, hvordan konfigurerer man det uden almindelige problemer, hvordan løser man typiske fejl (sikker opstart, kernelnedbrud, gemte stier) og hvordan man udnytter nedbrud til at undersøge vmcore. Hvis dit system går ned flere gange om dagen, er her en realistisk og detaljeret handlingsplan for at få styr på tingene.

Hvad er kdump og crash, og hvorfor er de vigtige?

Kdump-funktionen aktiverer en kernedump-mekanisme i tilfælde af en katastrofal fejl. Kdump reserverer hukommelse til en anden capture-kerne som startes af systemkaldet kexec når hovedkernen går i panik, og derfra dumper den stoppede systems hukommelse til disken.

I mange distributionsbilleder for virksomheder findes systemet delvist eller fuldt forberedt til at generere crashdumps afhængigt af billedets dato. Det er dog en god idé at kontrollere og fuldføre konfigurationen for at sikre, at dumpfilen genereres og gemmes på den korrekte placering.

Red Hats crashværktøj er de facto standarden for kernel dump-analyse. Crash giver dig mulighed for at inspicere dumps hentet med kdump, makedumpfile, diskdump og andre., og kan endda arbejde på kørende systemer ved hjælp af /dev/mem eller, i Red Hat-derivater, /dev/crashDet er mere kraftfuldt end at bruge gdb på /proc/kcore på grund af begrænsninger i adgang til interne kernestrukturer og kravene til den passende binære fil.

Red Hat anbefaler, især i kritiske miljøer, at administratorer Opdater og test kexec-tools regelmæssigt inden for den normale kerneopdateringscyklus, og i endnu højere grad når nye kernefunktioner udgives. Denne praksis reducerer overraskelser, når systemtilgængeligheden er mest på spil.

Korrekt konfiguration og dumpstier

Først og fremmest skal du forstå, hvilke filer du får. I en typisk dump vil du se mindst vmcore med kernehukommelse og hjælpefiler som f.eks. vmcore-dmesg.txt o kexec-dmesg.log, nyttig til at rekonstruere konteksten for opkald og beskeder før nedbruddet.

Det er vigtigt at definere klart, hvor dumpen gemmes. Et typisk tilfælde i systemer, der monterer dumpdestinationen i /var/crash er utilsigtet at ende med indlejrede ruter af stilen /var/crash/var/crashDette sker, når filsystemet er monteret på /var/crash og også i /etc/kdump.conf er etableret path /var/crashResultatet er, at dumpfilen falder ind i den duplikerede sti.

Løsningen er ligetil: hvis dumpmonteringspunktet allerede er /var/crash, definerer i kdump.conf path / i stedet for path /var/crashPå denne måde undgår du indlejring, og dine dumps vises i den forventede mappe. Brug et konfigurationsfilfilter (ignorer kommentarer og tomme linjer) for at sikre, at de aktive indstillinger matcher den faktiske montering af destinationen.

På distributioner med GRUB indstilles hukommelsesallokeringen for capture-kernen med parameteren crashkernel= i linjen af støvleDet er almindeligt at teste værdier som f.eks. crashkernel=128M, 256M, 512M o autoog regenerer konfigurationen med grub2-mkconfig o update-grub Ifølge distributionens familie garanterer reservation af hukommelse dog ikke i sig selv, at tjenesten starter, hvis der er andre nedbrud.

I Ubuntu/Debian-miljøer er en typisk sekvens at installere pakken linux-crashdump, aktivere tjenesten kdump-tools og justere /etc/default/grub med parameter crashkernel= antes de update-grub. Kommandoen kdump-config show Den fortæller dig status: dump-mappe (/var/crash), links til vmlinuz e initrd fra capture-kernen, den reserverede adresse, og om den er klar til at køre kdump. Hvis du ser "nuværende tilstand: Ikke klar til kdump" eller "ingen kexec-kommando registreret", mangler capture-kernen en effektiv indlæsning.

En anden grundlæggende detalje til analyse: nedbrud kræver en kernebinærfil med symboler. Den relevante fil til analyse er vmlinux (ukomprimeret, med fejlfindingssymboler), mens vmlinuz Dette er den komprimerede version, der indlæses ved opstart. Uden den korrekte binære fil kan et programnedbrud klage over, at det ikke kan finde den opstartede kerne, og bede om den korrekte navneliste. Installer -dbg/-debuginfo-pakkerne til din kerne for at sikre den bedste scanningsoplevelse.

Almindelige problemer, hvordan man løser dem, og crashanalyse

Hvis du kører efter genstart systemctl status kdump.service Og hvis du ser, at det fejler, er det første, du skal gøre, at læse beskederne omhyggeligt. Et meget almindeligt tilfælde fra det virkelige liv viser: "Sikker opstart er aktiveret. Bruger kexec-filbaseret syscall" efterfulgt af “failed to load kdump kernel”. Med Sikker opstart aktiveret, gennemtvinger systemet brugen af ​​den “filbaserede” variant af kexec, hvilket kan fejle, hvis capture-kernen eller dens initrd ikke er signeret som forventet af firmwaren.

Hvad skal man kontrollere i det tilfælde: bekræfte at Capture-kernen og dens initrd er egnede til sikker opstart, at pakken kexec-tools er opdateret, og der er ingen usignerede kritiske moduler i kdump initrd. Hvis dit sikkerhedssystem tillader det, kan midlertidig deaktivering af Secure Boot for at isolere problemet hjælpe med at afgøre, om den grundlæggende årsag til problemet er signaturen eller hukommelsesallokeringen.

På Ubuntu/Debian er en anden illustrativ fejl ved indlæsning af kdump: "Kunne ikke finde et ledigt hukommelsesområde på 0x943c000 bytes… locate_hole mislykkedes". Dette indikerer, at der ikke kan findes en sammenhængende hukommelsesplads med den nødvendige størrelse til capture-kernen. Typiske årsager omfatter hukommelsesfragmentering, utilstrækkelig allokering eller konflikter med det aktuelle layout.

Praktiske løsninger for “locate_hole failed” og lignende:

• Reducer eller juster reserven: prøv med crashkernel=256M hvis du var på 512M eller omvendt; på nogle computere fungerer mellemværdier bedre end auto.
• Den starter op med færre parametre, der fragmenterer hukommelsen ved opstart, og sørg for at regenerere GRUB efter ændringerne (grub2-mkconfig o update-grub).
• Kontroller at linkene til /var/lib/kdump/vmlinuz e initrd.img peger på den korrekte capture-kerne, og at der er din kdump initrd.
• På maskiner med krævende enheder eller IOMMU'er kan crashkernel-værdier med segmenter (f.eks. zone-reserverede ordninger) hjælpe; hvis din distribution dokumenterer foruddefinerede profiler, prøv dem før du opfinder en.

Hvis tjenesten rapporterer “kdump: Starter kdump:” og “Hovedproces afsluttet, status=1/FEJL”, skal du gå tilbage til det grundlæggende: Blev capture-kernen faktisk indlæst? Løb kdumpctl start o kdump-config load afhængigt af dit system, og undersøg det fulde output. Meddelelserne om oprettelse af initrd, symbolske links og derefter en hukommelsesallokeringsfejl peger alle på den samme rod: et manglende sammenhængende rum af den ønskede størrelse.

Husk også, at det grafiske miljø (KDE, GNOME osv.) ikke har nogen plads i denne film: kdump fungerer på kerne- og boot-niveauHvis nogen spørger dig "hvordan man får det til at virke i KDE", er svaret, at det ikke er DE'en, der spiller ind, men firmwaren (Secure Boot), bootloaderen, hukommelsesallokeringen og den korrekte pakning af capture-kernen/initrd.

Vi vender tilbage til ruternes særegenhed: hvis du ser, at den vælter ind /var/crash/var/crash, tjek ud /etc/kdump.confNår dumpmålet er monteret på /var/crash og muligheden path det er også /var/crash, resultatet er den duplikerede rute. Etablerer path / og sagen løst.

Når du har genereret dumpet (f.eks. vmcore sammen med vmcore-dmesg.txt y kexec-dmesg.log), er det tid til at bruge crash. Crash indlæser vmcore og binærfil vmlinux med symboler og åbner et rigt analysemiljø: du kan liste processer, kalde stakke, moduler, hukommelse, låse osv. Det er den ideelle tilgang sammenlignet med at prøve gdb med /proc/kcore, som ofte er begrænset og afhængig af, hvordan kernen blev kompileret.

For at arbejde på et system, der ikke er i produktion (eller efter kopiering af filerne), skal du starte et nedbrud, der angiver vmcore og vmlinux egnet. Uden den korrekte vmlinux halter analysen, fordi der mangler symboler til at fortolke interne strukturer. Hvis din distribution tilbyder -debuginfo eller -dbg kernepakker, skal du installere dem og bruge deres vmlinux svarende til vmcore-versionen.

Det er vigtigt at forstå sikkerhedsmæssige konsekvenser. En vmcore indeholder "alt", der var i hukommelsen på tidspunktet for nedbruddet: følsomme data, nøgler, samtalefragmenter og alt, der var levende i processer og kerne. Derfor placeringen og tilladelserne for /var/crash Og dumps bør behandles med samme omhu som andre hemmeligheder. Lad dem ikke være tilgængelige for brugere, der ikke burde se dem.

Hvis du ikke har brug for en fuld kerneldump, og målet er at fejlfinde en specifik proces, er en mindre invasiv strategi at generere en procesdump med værktøjer som gcore. Procesdumps er mindre og mere håndterbare, og giver dig mulighed for at isolere use cases (f.eks. en specifik app, der går ned). Risikoen for at eksponere følsomme procesdata forbliver dog, så de samme forholdsregler gælder opbevaring og tilladelser.

For at lukke kredsløbet om god operationel praksis: I missionskritiske miljøer skal du sørge for, at Test af kdump efter opdatering af kernen og kexec-toolsDet er bedre at opdage, at "capture kernel ikke vil boote" under et vedligeholdelsesvindue end midt i en reel hændelse. Og dokumenter stien, opbevaringen og proceduren for sikker fjernelse/overførsel af vmcore til udviklings- eller supportteamet.

Praktisk opsummering af tegn og handlinger:

• Status siger "Ikke klar til kdump" eller registrerer ikke kexec-kommandoen: manglende indlæsning af capture-kerneTjek crashkernel, kdump initrd, og genindlæs med din distributions værktøj.
• Sikker opstart aktiv og “kexec filbaseret syscall”: verificerer signaturer og kompatibilitet fra kernel-/initrd-optagelsen eller test uden sikker opstart for at isolere fejlen.
• "locate_hole mislykkedes": sæt størrelse på crashkernel= og reducerer fragmentering ved opstart; bekræft links og regenerer GRUB.
• Dumpet ind /var/crash/var/crash: korrigerer path / en kdump.conf når FS er monteret på /var/crash.

Når alt er på plads, er det ideelle flow: panik opstår, kexec starter capture-kernen, makedumpfile indsamler hukommelsen og gemmer vmcore til den aftalte sti, og du eller dit team åbner casen med crash og vmlinux tilsvarende. Det er den korteste vej mellem hændelse og læring., og den der sparer dig for at gentage fejlen uden synlighed.

Selvom hver platform har sine nuancer, forbliver de grundlæggende principper de samme: reserver tilstrækkelig og sammenhængende hukommelse, overhold kravene til sikker opstart, når den er aktiv, juster dumpstien korrekt med monteringspunktet, og hav altid en vmlinux med håndtegnede symboler til ulykkesanalyse. Med disse brikker på plads, holder kdump op med at være et mysterium og bliver din sorte boks. når kernen beslutter sig for at lande uden varsel.

relateret artikel:

BSOD og Kernel Panic: Forskelle og sammenligning mellem Windows og Linux/Unix

Isaac

Passioneret forfatter om bytes-verdenen og teknologien generelt. Jeg elsker at dele min viden gennem skrivning, og det er det, jeg vil gøre i denne blog, vise dig alle de mest interessante ting om gadgets, software, hardware, teknologiske trends og mere. Mit mål er at hjælpe dig med at navigere i den digitale verden på en enkel og underholdende måde.