Włączanie Kdump w Linuksie: zrzut przy kernel panic

Poziom: Średniozaawansowany / Senior
Szacowany czas: ~30 minut
Cel: Skonfigurowanie przechwytywania zrzutów awarii (crash dump) kdump w systemie Linux przy panice jądra, umożliwiając niezawodną analizę po awarii (post-mortem) usterek w środowisku produkcyjnym. Ten przewodnik wyjaśnia, jak włączyć kdump w systemie Linux, obejmując pełną konfigurację zrzutu awarii w systemie Linux, od rezerwacji pamięci po analizę vmcore.

Wprowadzenie

Panika jądra (kernel panic) zatrzymuje system, a bez zrzutu awarii nie masz żadnych danych do pracy. Kdump – standardowy framework zrzutów awarii jądra w systemie Linux – rozwiązuje ten problem: wstępnie ładuje jądro przechwytujące do zarezerwowanej pamięci, a gdy główne jądro ulegnie panice, kexec uruchamia to jądro przechwytujące, aby zapisać pełny obraz pamięci (vmcore) na dysku. W tym samouczku dowiesz się, jak włączyć kdump w systemie Linux w celu przechwytywania zrzutów awarii jądra Linux na systemach Ubuntu, Debian i opartych na RHEL. Pokażemy Ci dokładnie, jak włączyć systemy kdump wymagane przez Linux, wraz z krokami analizy post-mortem vmcore w systemie Linux.

Czym jest Kdump?

Kdump to mechanizm zrzucania awarii jądra, który wykorzystuje kexec do uruchomienia drugorzędnego jądra przechwytującego z zarezerwowanego obszaru pamięci za każdym razem, gdy główne jądro ulega panice. Jądro przechwytujące działa z ograniczoną pamięcią (ustawioną przez parametr rozruchu crashkernel) i zapisuje obraz pamięci awaryjnego jądra na dysku jako vmcore – pełny plik zrzutu pamięci, który można przeanalizować za pomocą narzędzia crash lub gdb. Usługa kdump (kdump.service w systemach opartych na RHEL lub kdump-tools.service w systemach opartych na Debianie) zarządza ładowaniem jądra przechwytującego w czasie rozruchu.

Kluczowe komponenty:

• Kexec: wywołanie systemowe i narzędzie przestrzeni użytkownika (userspace), które ładuje jądro przechwytujące do zarezerwowanej pamięci.
• Crashkernel: parametr rozruchu, który informuje główne jądro, ile pamięci RAM zarezerwować do działania kdump w systemie Linux (np. crashkernel=256M).
• Vmcore: plik wyjściowy zawierający pełny zrzut pamięci, zapisywany domyślnie w /var/crash.
• /var/crash: domyślny katalog, w którym kdump przechowuje pliki vmcore po panice jądra.

Wymagania wstępne

Zanim zaczniesz, upewnij się, że spełnione są następujące warunki:

• System operacyjny: Ubuntu 22.04/24.04 LTS, Debian 12/13 lub RHEL/CentOS/AlmaLinux 9/10 (Przetestowano i zweryfikowano na Ubuntu 24.04, Debianie 13 i AlmaLinux 10).
• Dostęp: Dostęp sudo lub root do serwera.
• RAM: Minimum 2 GB łącznie. Kdump rezerwuje część pamięci systemowej (zazwyczaj 256 MB) dla jądra przechwytującego – systemy z małą ilością pamięci mogą nie mieć wystarczającego zapasu.
• Miejsce na dysku: Co najmniej tyle wolnego miejsca w /var/crash, ile system ma pamięci RAM (vmcore może być tak duży jak pamięć fizyczna).
• Wymagana wiedza: pewne posługiwanie się wierszem poleceń Linuxa, podstawowa edycja plików i znajomość parametrów rozruchu GRUB.
• Okno na restart: Konfiguracja parametru crashkernel wymaga ponownego uruchomienia, aby zaczęła obowiązywać.

Krok 1: Zainstaluj pakiety kdump i kexec

Kdump opiera się na kexec-tools (komponent przestrzeni użytkownika kexec/kdump w systemie Linux) i pomocnikach specyficznych dla dystrybucji.

Ubuntu/Debian:

sudo apt update && sudo apt install kdump-tools kexec-tools crash -y

Podczas interaktywnej instalacji w systemie Ubuntu może pojawić się monit debconf z pytaniem o automatyczną konfigurację parametru crashkernel. Wybierz Tak, jeśli zostaniesz o to zapytany. Jeśli monit się nie pojawi (np. w trybie nieinteraktywnym), crashkernel jest konfigurowany automatycznie za pomocą pliku drop-in. Jeśli będziesz musiał później dostosować wartość, Krok 2 obejmuje konfigurację ręczną.

RHEL/CentOS/AlmaLinux:

sudo dnf install kexec-tools crash -y

W systemach opartych na RHEL pakiet kexec-tools dostarcza wszystkiego, co jest potrzebne: plik binarny kexec, usługę kdump i domyślne pliki konfiguracyjne.

Krok 2: Skonfiguruj parametr rozruchu crashkernel

Parametr crashkernel informuje jądro, ile pamięci zarezerwować dla kdump w systemie Linux w czasie rozruchu. Bez tej rezerwacji jądro przechwytujące nie ma gdzie działać. Zrozumienie, jak poprawnie skonfigurować wartości parametru crashkernel, jest kluczowe – zbyt mało i jądro przechwytujące się nie uruchomi; zbyt dużo i zmarnujesz produkcyjną pamięć RAM.

2.1 Sprawdź bieżącą konfigurację

Najpierw sprawdź, czy crashkernel jest już ustawiony:

cat /proc/cmdline | grep crashkernel

Jeśli dane wyjściowe zawierają wpis crashkernel=, parametr jest już skonfigurowany. Możesz zweryfikować zarezerwowaną ilość i przejść do Kroku 3, jeśli spełnia Twoje potrzeby.

2.2 Skonfiguruj parametr crashkernel w systemach opartych na GRUB

Ubuntu/Debian:

Przed modyfikacją głównej konfiguracji GRUB sprawdź, czy istnieje już plik drop-in:

cat /etc/default/grub.d/kdump-tools.cfg

Jeśli pakiet już skonfigurował tutaj crashkernel, zmodyfikuj ten plik, aby uniknąć zduplikowanych wpisów w grub.cfg. W przeciwnym razie otwórz główny plik domyślnych ustawień GRUB:

sudo nano /etc/default/grub

Znajdź linię GRUB_CMDLINE_LINUX_DEFAULT i dodaj parametr crashkernel. Dla większości serwerów produkcyjnych z 4 GB lub więcej pamięci RAM, 256 MB wystarczy do zarezerwowania pamięci dla kdump w systemie Linux:

GRUB_CMDLINE_LINUX_DEFAULT="quiet crashkernel=256M"

Dla serwerów z mniej niż 4 GB pamięci RAM użyj crashkernel=128M. Dla systemów z 64 GB lub więcej rozważ crashkernel=512M. Możesz również użyć składni automatycznego skalowania crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M, aby dynamicznie konfigurować wartości parametru crashkernel w oparciu o zainstalowaną pamięć RAM.

Zapisz i zamknij plik, a następnie wygeneruj ponownie konfigurację GRUB:

sudo update-grub

RHEL/CentOS/AlmaLinux:

Dla RHEL/AlmaLinux 8+ parametr crashkernel znajduje się w GRUB_CMDLINE_LINUX (bez _DEFAULT). Jednak w nowoczesnych systemach używających BLS (Boot Loader Specification) najbezpieczniejszym i zalecanym sposobem aktualizacji wiersza poleceń jądra jest użycie grubby zamiast bezpośredniej modyfikacji /etc/default/grub:

sudo grubby --update-kernel=ALL --args="crashkernel=256M"

Jeśli musisz zmodyfikować to ręcznie za pomocą konfiguracji GRUB, edytuj /etc/default/grub i zaktualizuj GRUB_CMDLINE_LINUX. Następnie wygeneruj ponownie konfigurację (ścieżki różnią się w zależności od trybu rozruchu):

# Dla systemów z legacy BIOS:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# Dla systemów UEFI (np. AlmaLinux):
sudo grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg

2.3 Uruchom ponownie, aby zastosować rezerwację crashkernel

Rezerwacja pamięci crashkernel wchodzi w życie dopiero po ponownym uruchomieniu:

sudo reboot

Po ponownym uruchomieniu systemu sprawdź, czy rezerwacja jest aktywna:

cat /proc/cmdline | grep crashkernel

Oczekiwane dane wyjściowe obejmują:

crashkernel=256M

Potwierdź również, że pamięć została faktycznie zarezerwowana:

sudo dmesg | grep -i "crashkernel reserved"

Powinieneś zobaczyć linię podobną do:

crashkernel reserved: 0x... - 0x... (NNN MB)

Jeśli rezerwacja nie powiodła się (komunikat mówi "crashkernel reservation failed"), może być konieczne zwiększenie lub zmniejszenie wartości. Jest to powszechny krok w rozwiązywaniu problemów z paniką jądra w systemie Linux – jądro nie mogło znaleźć ciągłego bloku o żądanym rozmiarze.

Krok 3: Skonfiguruj ustawienia usługi kdump w systemie Linux

Gdy pamięć jest już zarezerwowana, skonfiguruj, gdzie i jak kdump przechowuje vmcore.

3.1 Konfiguracja w RHEL/CentOS/AlmaLinux

Głównym plikiem konfiguracyjnym jest /etc/kdump.conf. Otwórz go:

sudo nano /etc/kdump.conf

Krytyczne dyrektywy:

path /var/crash
core_collector makedumpfile -l --message-level 7 -d 31

• path /var/crash: ustawia docelowy katalog vmcore. Wszystkie zrzuty awarii trafiają tutaj.
• core_collector makedumpfile: kompresuje zrzut i filtruje niepotrzebne strony. Flaga -d 31 wyklucza strony zerowe, pamięć podręczną, dane użytkownika i wolne strony – zazwyczaj redukując vmcore do 10-20% całkowitej pamięci RAM.

3.2 Konfiguracja w Ubuntu/Debian

W systemach opartych na Debianie konfiguracja kdump-tools znajduje się w /etc/default/kdump-tools. Otwórz go:

sudo nano /etc/default/kdump-tools

Upewnij się, że te linie są ustawione:

USE_KDUMP=1
KDUMP_COREDIR="/var/crash"
KDUMP_CORE_COLLECTOR="makedumpfile -l --message-level 7 -d 31"

USE_KDUMP=1 włącza usługę kdump. Bez tego jądro przechwytujące nie zostanie załadowane podczas rozruchu.

Krok 4: Włącz i uruchom usługę kdump

To ostatni krok dotyczący tego, jak włączyć kdump w systemie Linux. Włącz usługę kdump, aby jądro przechwytujące ładowało się automatycznie przy każdym rozruchu, kończąc konfigurację kexec/kdump w systemie Linux.

Ubuntu/Debian:

sudo systemctl enable kdump-tools
sudo systemctl start kdump-tools

RHEL/CentOS/AlmaLinux:

sudo systemctl enable kdump
sudo systemctl start kdump

Sprawdź, czy usługa działa:

Ubuntu/Debian:

sudo systemctl status kdump-tools

RHEL/CentOS/AlmaLinux:

sudo systemctl status kdump

Oczekiwane dane wyjściowe obejmują:

Active: active (exited)

Stan "exited" (zakończony) jest normalny – usługa kdump ładuje jądro przechwytujące do zarezerwowanej pamięci, a następnie wychodzi. Nie działa jako trwały demon.

Krok 5: Weryfikacja i testowanie

5.1 Zweryfikuj, czy kdump jest gotowy

Potwierdź, że jądro przechwytujące jest załadowane i gotowe do zadziałania przy panice jądra:

cat /sys/kernel/kexec_crash_loaded

Oczekiwane dane wyjściowe:

1

Wartość 1 oznacza, że jądro przechwytujące jest załadowane. Wartość 0 oznacza, że kdump nie działa – wróć i sprawdź status usługi oraz rezerwację crashkernel.

Możesz również sprawdzić, ile pamięci zostało odłożone na rezerwację pamięci dla kdump w systemie Linux:

cat /sys/kernel/kexec_crash_size

Zwraca to rezerwację w bajtach.

5.2 Wywołaj testowy crash

Włącz wyzwalacze SysRq, a następnie wymuś awarię:

echo 1 | sudo tee /proc/sys/kernel/sysrq
echo c | sudo tee /proc/sysrq-trigger

System ulegnie panice. Jeśli kdump jest poprawnie skonfigurowany, jądro przechwytujące uruchomi się, zapisze vmcore w /var/crash, a system uruchomi się ponownie automatycznie.

5.3 Potwierdź, że vmcore zostało przechwycone

Po ponownym uruchomieniu sprawdź /var/crash w poszukiwaniu zrzutu:

ls -lh /var/crash/

Oczekiwane dane wyjściowe (format różni się w zależności od dystrybucji):

Rodzina RHEL (AlmaLinux/CentOS):

drwxr-xr-x 2 root root 4.0K May 23 14:00 127.0.0.1-2026-05-23-14:00:01/

Wewnątrz tego katalogu ze znacznikiem czasu znajdziesz vmcore (zrzut pamięci) i vmcore-dmesg.txt (dziennik jądra).

Rodzina Debian (Ubuntu/Debian):

drwxr-xr-x 2 root root 4.0K May 23 14:00 202605231400/

Wewnątrz tego katalogu pliki są zazwyczaj nazwane dump.<znacznik_czasu> i dmesg.<znacznik_czasu>.

Sprawdź wewnątrz katalogu:

ls -lh /var/crash/*/

Zobaczenie tych plików potwierdza, że Twój potok zrzutów awarii jądra Linux jest w pełni sprawny.

Krok 6: Analiza pliku vmcore

Przechwycenie zrzutu awarii jest przydatne tylko wtedy, gdy możesz go odczytać. Narzędzie crash to standardowe narzędzie, na które administratorzy systemu Linux polegają w analizie vmcore i rozwiązywaniu problemów z paniką jądra w systemie Linux.

6.1 Zainstaluj jądro debugowania

Narzędzie crash wymaga symboli debugowania dla dokładnej wersji jądra, które uległo panice.

Ubuntu:

echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse" | sudo tee /etc/apt/sources.list.d/ddebs.list
sudo apt install ubuntu-dbgsym-keyring
sudo apt update
sudo apt install linux-image-unsigned-$(uname -r)-dbgsym

Debian:

echo "deb http://deb.debian.org/debian-debug/ $(lsb_release -cs)-debug main" | sudo tee /etc/apt/sources.list.d/debian-debug.list
sudo apt update
sudo apt install linux-image-$(uname -r)-dbg

RHEL/CentOS/AlmaLinux:

sudo dnf --enablerepo='*-debuginfo' install -y kernel-debuginfo-$(uname -r)

6.2 Otwórz vmcore za pomocą crash

Przed uruchomieniem crash upewnij się, że symbole debugowania są zainstalowane i pasują do wersji Twojego jądra, aby nie uruchamiać go na ślepo:

# RHEL/Debian:
ls -lh /usr/lib/debug/lib/modules/$(uname -r)/vmlinux

# Ubuntu:
ls -lh /usr/lib/debug/boot/vmlinux-$(uname -r)

Przejdź do katalogu zrzutu awarii i otwórz vmcore (dokładne polecenie różni się w zależności od systemu operacyjnego):

RHEL/CentOS/AlmaLinux:

sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/vmcore

Debian:

sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/dump.*

Ubuntu:

sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/*/dump.*

Narzędzie crash ładuje się i przenosi Cię do interaktywnej powłoki. Kluczowe polecenia do wstępnego triage'u:

bt          # ślad wsteczny (backtrace) zadania, które wywołało panikę
log         # bufor dziennika jądra (takie samo jak dmesg w momencie paniki)
ps          # lista procesów w momencie awarii
mod         # załadowane moduły jądra
sys         # informacje o systemie

Wpisz exit lub quit, aby wyjść z powłoki crash.

Wycofanie zmian (Rollback)

Aby cofnąć konfigurację kdump i odzyskać zarezerwowaną pamięć:

1. Zatrzymaj i wyłącz usługę kdump:

Ubuntu/Debian:

sudo systemctl disable --now kdump-tools

RHEL/CentOS/AlmaLinux:

sudo systemctl disable --now kdump

2. Usuń parametr crashkernel:

Ubuntu/Debian:

Otwórz plik konfiguracyjny drop-in:

sudo nano /etc/default/grub.d/kdump-tools.cfg

Usuń parametr crashkernel (jeśli dodałeś go ręcznie do /etc/default/grub, zamiast tego edytuj ten plik).

RHEL/CentOS/AlmaLinux:

Otwórz plik domyślnych ustawień GRUB:

sudo nano /etc/default/grub

Usuń crashkernel=256M z linii GRUB_CMDLINE_LINUX lub GRUB_CMDLINE_LINUX_DEFAULT.

Wygeneruj ponownie GRUB:

Ubuntu/Debian:

sudo update-grub

RHEL/CentOS/AlmaLinux:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

3. Uruchom ponownie, aby zwolnić zarezerwowaną pamięć:

sudo reboot

4. Usuń pakiety (opcjonalnie):

Ubuntu/Debian:

sudo apt remove --purge kdump-tools kexec-tools crash -y

RHEL/CentOS/AlmaLinux:

sudo dnf remove kexec-tools crash -y

Rozwiązywanie problemów

Usługa kdump nie uruchamia się

Sprawdź dziennik, aby poznać przyczynę:

journalctl -xeu kdump

Typowe przyczyny:

• Brak rezerwacji crashkernel. Zweryfikuj za pomocą cat /proc/cmdline | grep crashkernel. Jeśli brakuje, powtórz Krok 2.
• Niewystarczająca zarezerwowana pamięć. Jądro przechwytujące potrzebuje wystarczającej ilości pamięci RAM do zainicjowania i zapisania zrzutu. Spróbuj zwiększyć wartość (np. crashkernel=512M).
• Konflikt z Secure Boot. Niektóre konfiguracje Secure Boot uniemożliwiają kexec ładowanie niepodpisanych jąder. Podpisz jądro przechwytujące lub wyłącz Secure Boot w BIOS-ie.

Vmcore nie jest zapisywane po panice

• Miejsce na dysku. Upewnij się, że /var/crash ma wystarczającą ilość wolnego miejsca. Vmcore może zbliżać się rozmiarem do fizycznej pamięci RAM (przed kompresją makedumpfile).
• Zła ścieżka. Potwierdź, że path w /etc/kdump.conf (lub KDUMP_COREDIR w /etc/default/kdump-tools) wskazuje na zamontowany system plików z uprawnieniami do zapisu.
• Odmowa SELinux. W systemach opartych na RHEL sprawdź ausearch -m avc -ts recent pod kątem odmów związanych z kdump.

System zawiesza się zamiast przechwytywać zrzut

Zazwyczaj wskazuje to na problem sprzętowy lub sterownika uniemożliwiający przejście kexec/kdump w systemie Linux. Spróbuj dodać irqpoll nr_cpus=1 reset_devices do wiersza poleceń jądra kdump w /etc/sysconfig/kdump (RHEL) lub /etc/default/kdump-tools (Debian) jako KDUMP_CMDLINE_APPEND.

Podsumowanie

To wszystko. Crashkernel rezerwuje pamięć, usługa kdump ładuje jądro przechwytujące podczas rozruchu, a przy zrzucie awarii paniki jądra Linux vmcore trafia do /var/crash – gotowy do konfiguracji zrzutu awarii w systemie Linux, której możesz naprawdę zaufać. Masz teraz działającą konfigurację, aby automatycznie włączyć przechwytywanie zrzutów awarii kdump w systemie Linux; w celu głębszego rozwiązywania problemów z paniką jądra w systemie Linux, podaj vmcore do crash i zacznij od śladu wstecznego.

Wersja dokumentu: 1.0
Ostatnia aktualizacja: Maj 2026
Właściciel: Zespół Dokumentacji Technicznej