Activer Kdump sous Linux : dumps de kernel panic

Niveau : Intermédiaire / Senior
Temps estimé : ~30 minutes
Objectif : Configurer la capture de vidage sur incident (crash dump) kdump sous Linux pour les paniques du noyau, permettant une analyse post-mortem fiable des défaillances en production. Ce guide explique comment activer kdump sous Linux, couvrant toute la configuration du vidage sur incident Linux, de la réservation de mémoire à l'analyse du vmcore.

Introduction

Une panique du noyau (kernel panic) arrête le système, et sans vidage sur incident, vous n'avez aucune donnée avec laquelle travailler. Kdump, le framework standard de vidage sur incident du noyau Linux, résout ce problème : il précharge un noyau de capture dans la mémoire réservée, et lorsque le noyau principal panique, kexec démarre ce noyau de capture pour écrire une image complète de la mémoire (vmcore) sur le disque. Dans ce tutoriel, vous apprendrez comment activer kdump sous Linux pour la capture de vidage sur incident de panique du noyau Linux sur les systèmes Ubuntu, Debian et basés sur RHEL. Nous vous montrerons exactement comment activer les systèmes kdump requis par Linux, avec les étapes d'analyse post-mortem du vmcore sous Linux incluses.

Qu'est-ce que Kdump ?

Kdump est un mécanisme de vidage sur incident du noyau qui utilise kexec pour démarrer un noyau de capture secondaire à partir d'une région de mémoire réservée chaque fois que le noyau principal panique. Le noyau de capture s'exécute avec une mémoire limitée (définie par le paramètre de démarrage crashkernel) et écrit l'image mémoire du noyau défaillant sur le disque sous forme de vmcore, un fichier de vidage mémoire complet qui peut être analysé avec l'utilitaire crash ou gdb. Le service kdump (kdump.service sur les systèmes basés sur RHEL ou kdump-tools.service sur les systèmes basés sur Debian) gère le chargement du noyau de capture au moment du démarrage.

Composants clés :

• Kexec : l'appel système et l'outil en espace utilisateur qui charge le noyau de capture dans la mémoire réservée.
• Crashkernel : le paramètre de démarrage qui indique au noyau principal combien de RAM réserver pour l'opération kdump sous Linux (par exemple, crashkernel=256M).
• Vmcore : le fichier de sortie contenant le vidage mémoire complet, écrit dans /var/crash par défaut.
• /var/crash : le répertoire par défaut où kdump stocke les fichiers vmcore après une panique du noyau.

Prérequis

Avant de commencer, assurez-vous que les conditions suivantes sont remplies :

• Système d'exploitation : Ubuntu 22.04/24.04 LTS, Debian 12/13, ou RHEL/CentOS/AlmaLinux 9/10 (Testé et vérifié sur Ubuntu 24.04, Debian 13 et AlmaLinux 10).
• Accès : Accès sudo ou root au serveur.
• RAM : Minimum 2 Go au total. Kdump réserve une partie de la mémoire système (généralement 256 Mo) pour le noyau de capture ; les systèmes à faible mémoire peuvent ne pas avoir assez de marge.
• Espace disque : Au moins autant d'espace libre dans /var/crash que votre système a de RAM (un vmcore peut être aussi grand que la mémoire physique).
• Connaissances requises : utilisation maîtrisée de la ligne de commande Linux, édition de base de fichiers et familiarité avec les paramètres de démarrage GRUB.
• Fenêtre de redémarrage : La configuration du paramètre crashkernel nécessite un redémarrage pour prendre effet.

Étape 1 : Installer les paquets kdump et kexec

Kdump s'appuie sur kexec-tools (le composant en espace utilisateur de kexec/kdump sous Linux) et sur des assistants spécifiques à la distribution.

Ubuntu/Debian :

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

Lors d'une installation interactive sur Ubuntu, une invite debconf peut apparaître pour demander de configurer automatiquement le paramètre crashkernel. Sélectionnez Oui si on vous le demande. Si l'invite n'apparaît pas (par exemple, en mode non interactif), crashkernel est configuré automatiquement via un fichier drop-in. Si vous devez ajuster la valeur plus tard, l'Étape 2 couvre la configuration manuelle.

RHEL/CentOS/AlmaLinux :

sudo dnf install kexec-tools crash -y

Sur les systèmes basés sur RHEL, le paquet kexec-tools fournit tout ce qui est nécessaire : le binaire kexec, le service kdump et les fichiers de configuration par défaut.

Étape 2 : Configurer le paramètre de démarrage crashkernel

Le paramètre crashkernel indique au noyau combien de mémoire réserver pour kdump sous Linux au moment du démarrage. Sans cette réservation, le noyau de capture n'a nulle part où s'exécuter. Comprendre comment configurer correctement les valeurs du paramètre crashkernel est essentiel : trop peu et le noyau de capture ne démarrera pas ; trop et vous gaspillerez de la RAM de production.

2.1 Vérifier la configuration actuelle

Tout d'abord, vérifiez si crashkernel est déjà défini :

cat /proc/cmdline | grep crashkernel

Si la sortie contient une entrée crashkernel=, le paramètre est déjà configuré. Vous pouvez vérifier la quantité réservée et passer à l'Étape 3 si elle répond à vos besoins.

2.2 Configurer le paramètre crashkernel sur les systèmes basés sur GRUB

Ubuntu/Debian :

Avant de modifier la configuration principale de GRUB, vérifiez si un fichier drop-in existe déjà :

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

Si le paquet a déjà configuré crashkernel ici, modifiez ce fichier à la place pour éviter les entrées en double dans grub.cfg. Sinon, ouvrez le fichier des valeurs par défaut principal de GRUB :

sudo nano /etc/default/grub

Trouvez la ligne GRUB_CMDLINE_LINUX_DEFAULT et ajoutez le paramètre crashkernel. Pour la plupart des serveurs de production avec 4 Go ou plus de RAM, 256 Mo sont suffisants pour réserver de la mémoire pour kdump sous Linux :

GRUB_CMDLINE_LINUX_DEFAULT="quiet crashkernel=256M"

Pour les serveurs avec moins de 4 Go de RAM, utilisez crashkernel=128M. Pour les systèmes avec 64 Go ou plus, envisagez crashkernel=512M. Vous pouvez également utiliser la syntaxe de mise à l'échelle automatique crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M pour configurer dynamiquement les valeurs du paramètre crashkernel en fonction de la RAM installée.

Enregistrez et fermez le fichier, puis régénérez la configuration GRUB :

sudo update-grub

RHEL/CentOS/AlmaLinux :

Pour RHEL/AlmaLinux 8+, le paramètre crashkernel se trouve dans GRUB_CMDLINE_LINUX (sans _DEFAULT). Cependant, sur les systèmes modernes utilisant BLS (Boot Loader Specification), la méthode la plus sûre et recommandée pour mettre à jour la ligne de commande du noyau consiste à utiliser grubby au lieu de modifier directement /etc/default/grub :

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

Si vous devez le modifier manuellement via les configurations GRUB, éditez /etc/default/grub et mettez à jour GRUB_CMDLINE_LINUX. Ensuite, régénérez la configuration (les chemins varient selon le mode de démarrage) :

# Pour les systèmes BIOS legacy :
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# Pour les systèmes UEFI (par exemple, AlmaLinux) :
sudo grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg

2.3 Redémarrer pour appliquer la réservation crashkernel

La réservation de mémoire crashkernel ne prend effet qu'après un redémarrage :

sudo reboot

Après le redémarrage du système, vérifiez que la réservation est active :

cat /proc/cmdline | grep crashkernel

La sortie attendue inclut :

crashkernel=256M

Confirmez également que la mémoire a été réellement réservée :

sudo dmesg | grep -i "crashkernel reserved"

Vous devriez voir une ligne comme :

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

Si la réservation a échoué (le message indique "crashkernel reservation failed"), vous devrez peut-être augmenter ou diminuer la valeur. C'est une étape courante de dépannage des paniques du noyau Linux : le noyau n'a pas pu trouver un bloc contigu de la taille demandée.

Étape 3 : Configurer les paramètres du service kdump sous Linux

La mémoire étant réservée, configurez où et comment kdump stocke le vmcore.

3.1 Configuration RHEL/CentOS/AlmaLinux

Le fichier de configuration principal est /etc/kdump.conf. Ouvrez-le :

sudo nano /etc/kdump.conf

Les directives critiques :

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

• path /var/crash : définit le répertoire cible du vmcore. Tous les vidages sur incident atterrissent ici.
• core_collector makedumpfile : compresse le vidage et filtre les pages inutiles. L'indicateur -d 31 exclut les pages zéro, le cache, les données utilisateur et les pages libres, réduisant généralement un vmcore à 10-20 % de la RAM totale.

3.2 Configuration Ubuntu/Debian

Sur les systèmes basés sur Debian, la configuration de kdump-tools se trouve dans /etc/default/kdump-tools. Ouvrez-le :

sudo nano /etc/default/kdump-tools

Assurez-vous que ces lignes sont définies :

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

USE_KDUMP=1 active le service kdump. Sans cela, le noyau de capture ne sera pas chargé au démarrage.

Étape 4 : Activer et démarrer le service kdump

C'est la dernière étape pour savoir comment activer kdump sous Linux. Activez le service kdump afin que le noyau de capture se charge automatiquement à chaque démarrage, complétant la configuration kexec/kdump sous Linux.

Ubuntu/Debian :

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

RHEL/CentOS/AlmaLinux :

sudo systemctl enable kdump
sudo systemctl start kdump

Vérifiez que le service est en cours d'exécution :

Ubuntu/Debian :

sudo systemctl status kdump-tools

RHEL/CentOS/AlmaLinux :

sudo systemctl status kdump

La sortie attendue inclut :

Active: active (exited)

L'état "exited" (sorti) est normal : le service kdump charge le noyau de capture dans la mémoire réservée, puis se termine. Il ne s'exécute pas comme un démon persistant.

Étape 5 : Vérification et test

5.1 Vérifier que kdump est prêt

Confirmez que le noyau de capture est chargé et prêt à se déclencher en cas de panique du noyau :

cat /sys/kernel/kexec_crash_loaded

Sortie attendue :

1

Une valeur de 1 signifie que le noyau de capture est chargé. Un 0 signifie que kdump n'est pas opérationnel ; revenez en arrière et vérifiez l'état du service et la réservation crashkernel.

Vous pouvez également inspecter combien de mémoire a été mise de côté pour réserver de la mémoire pour kdump sous Linux :

cat /sys/kernel/kexec_crash_size

Cela renvoie la réservation en octets.

5.2 Déclencher un crash de test

Activez les déclencheurs SysRq, puis forcez un crash :

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

Le système va paniquer. Si kdump est correctement configuré, le noyau de capture démarre, écrit le vmcore dans /var/crash et le système redémarre automatiquement.

5.3 Confirmer que le vmcore a été capturé

Après le redémarrage, vérifiez /var/crash pour le vidage :

ls -lh /var/crash/

Sortie attendue (le format varie selon la distribution) :

Famille 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/

À l'intérieur de ce répertoire horodaté, vous trouverez vmcore (le vidage mémoire) et vmcore-dmesg.txt (le journal du noyau).

Famille Debian (Ubuntu/Debian) :

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

À l'intérieur de ce répertoire, les fichiers sont généralement nommés dump.<horodatage> et dmesg.<horodatage>.

Vérifiez à l'intérieur du répertoire :

ls -lh /var/crash/*/

Voir ces fichiers confirme que votre pipeline de vidage sur incident du noyau Linux est entièrement opérationnel.

Étape 6 : Analyser un fichier vmcore

Capturer un vidage sur incident n'est utile que si vous pouvez le lire. L'utilitaire crash est l'outil standard sur lequel les administrateurs Linux s'appuient pour l'analyse du vmcore et le dépannage des paniques du noyau Linux.

6.1 Installer le noyau de débogage

L'outil crash nécessite les symboles de débogage de la version exacte du noyau qui a paniqué.

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 Ouvrir le vmcore avec crash

Avant d'exécuter crash, vérifiez que les symboles de débogage sont installés et correspondent à votre version du noyau afin de ne pas l'exécuter à l'aveugle :

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

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

Naviguez vers le répertoire de vidage sur incident et ouvrez le vmcore (la commande exacte varie selon l'OS) :

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.*

L'utilitaire crash se charge et vous plonge dans un shell interactif. Commandes clés pour le triage initial :

bt          # trace arrière (backtrace) de la tâche ayant déclenché la panique
log         # tampon du journal du noyau (identique à dmesg au moment de la panique)
ps          # liste des processus au moment du crash
mod         # modules du noyau chargés
sys         # informations système

Tapez exit ou quit pour quitter le shell crash.

Annulation (Rollback)

Pour annuler la configuration kdump et récupérer la mémoire réservée :

1. Arrêter et désactiver le service kdump :

Ubuntu/Debian :

sudo systemctl disable --now kdump-tools

RHEL/CentOS/AlmaLinux :

sudo systemctl disable --now kdump

2. Supprimer le paramètre crashkernel :

Ubuntu/Debian :

Ouvrez le fichier de configuration drop-in :

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

Supprimez le paramètre crashkernel (si vous l'avez ajouté manuellement à /etc/default/grub, éditez ce fichier à la place).

RHEL/CentOS/AlmaLinux :

Ouvrez le fichier des valeurs par défaut de GRUB :

sudo nano /etc/default/grub

Supprimez crashkernel=256M de la ligne GRUB_CMDLINE_LINUX ou GRUB_CMDLINE_LINUX_DEFAULT.

Régénérer GRUB :

Ubuntu/Debian :

sudo update-grub

RHEL/CentOS/AlmaLinux :

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

3. Redémarrer pour libérer la mémoire réservée :

sudo reboot

4. Supprimer les paquets (optionnel) :

Ubuntu/Debian :

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

RHEL/CentOS/AlmaLinux :

sudo dnf remove kexec-tools crash -y

Dépannage

Le service kdump ne parvient pas à démarrer

Vérifiez le journal pour connaître la raison :

journalctl -xeu kdump

Causes courantes :

• Aucune réservation crashkernel. Vérifiez avec cat /proc/cmdline | grep crashkernel. S'il manque, répétez l'Étape 2.
• Mémoire réservée insuffisante. Le noyau de capture a besoin de suffisamment de RAM pour s'initialiser et écrire le vidage. Essayez d'augmenter la valeur (par exemple, crashkernel=512M).
• Conflit avec Secure Boot. Certaines configurations de Secure Boot empêchent kexec de charger des noyaux non signés. Signez le noyau de capture ou désactivez Secure Boot dans le BIOS.

Le vmcore n'est pas écrit après une panique

• Espace disque. Vérifiez que /var/crash dispose de suffisamment d'espace libre. Un vmcore peut approcher la taille de la RAM physique (avant la compression makedumpfile).
• Mauvais chemin. Confirmez que path dans /etc/kdump.conf (ou KDUMP_COREDIR dans /etc/default/kdump-tools) pointe vers un système de fichiers monté et accessible en écriture.
• Refus SELinux. Sur les systèmes basés sur RHEL, vérifiez ausearch -m avc -ts recent pour les refus liés à kdump.

Le système se fige au lieu de capturer le vidage

Cela indique généralement un problème matériel ou de pilote empêchant la transition kexec/kdump sous Linux. Essayez d'ajouter irqpoll nr_cpus=1 reset_devices à la ligne de commande du noyau kdump dans /etc/sysconfig/kdump (RHEL) ou /etc/default/kdump-tools (Debian) en tant que KDUMP_CMDLINE_APPEND.

Conclusion

C'est tout. Crashkernel réserve la mémoire, le service kdump charge le noyau de capture au démarrage, et lors d'un vidage sur incident de panique du noyau Linux, le vmcore atterrit dans /var/crash, prêt pour une configuration de vidage sur incident Linux en laquelle vous pouvez réellement avoir confiance. Vous disposez maintenant d'une configuration fonctionnelle pour activer automatiquement la capture de vidage sur incident kdump sous Linux ; pour un dépannage plus approfondi des paniques du noyau Linux, alimentez le vmcore à crash et commencez par la trace arrière.

Version du document : 1.0
Dernière mise à jour : Mai 2026
Propriétaire : Équipe de Documentation Technique