Sauvegarder et analyser les fichiers de vidage mémoire Linux avec kdump

Ce que kdump enregistre en cas de plantage du noyau

kdump prépare la sauvegarde d'une image mémoire du noyau Linux avant qu'un plantage ne se produise. Pour ce faire, une zone de mémoire est réservée au démarrage du noyau standard. Dans cette zone, un fichier séparé Noyau de capture chargé, qui peut être lancé via kexec en cas de plantage approprié.

Le noyau de capture fonctionne indépendamment du noyau système qui a planté et accède à son image mémoire via /proc/vmcore. Il peut enregistrer cette image vers une destination configurée. Le fichier sauvegardé est généralement appelé « vmcore » ; le fait qu'il contienne ou non l'intégralité des zones de mémoire d'origine dépend, entre autres, du filtrage sélectionné.

Les tâches sont distinctes : kdump enregistre et sauvegarde l'état, tandis que le programme crash analyse ensuite un dump existant. Cela permet notamment d'examiner les messages du noyau et les files d'attente des tâches. Un dump est un instantané et ne fournit pas automatiquement l'historique complet de l'erreur.

Un « oops » du noyau n'est pas synonyme de « panic » du noyau : un « oops » peut se produire sans que le système ne bascule immédiatement en état de « panic ». C'est pourquoi toutes les anomalies du noyau n'entraînent pas nécessairement la création d'un fichier kdump. En revanche, un « core dump » d'une application concerne l'état d'un processus et n'est pas un fichier vmcore du noyau.

Cette préparation est essentielle pour l'analyse ultérieure. Si aucun noyau de capture n'était préparé au moment du plantage ou si aucune image n'a été sauvegardée, kdump ne pourra pas reconstituer ultérieurement l'état perdu de la mémoire. Dans ce cas, les journaux disponibles et les autres données de diagnostic conservées après le redémarrage serviront de point de départ.

Conditions et limites de la collecte des données

Commencez par déterminer la distribution, la version et l'architecture du serveur. Les noms des paquets, la gestion des services, la configuration du démarrage et les destinations de stockage prises en charge en dépendent. Pour la configuration, utilisez la documentation propre à cette plateforme, plutôt que de combiner des commandes issues de différentes distributions ; le matériel et les pilotes installés ont également une incidence sur les exigences.

Le paramètre de démarrage crashkernel définit la Réservation de mémoire pour la capture en cas de panne. Cet espace n'est pas disponible pour le fonctionnement normal. Il n'existe pas de valeur forfaitaire fiable : référez-vous aux spécifications relatives à la distribution, à l'architecture et à l'équipement concret, et tenez compte des besoins en mémoire du système de capture.

La mémoire réservée ne suffit pas à elle seule. Le noyau de capture doit être chargé et pouvoir atteindre la cible configurée. Pour cela, les pilotes et composants nécessaires doivent être disponibles dans son environnement ; dans le cas d'une cible réseau, la connexion et l'accessibilité du poste distant font également partie des conditions préalables.

Prévoyez une capacité suffisante sur la destination pour les images attendues et leur stockage. La taille d'un dump dépend, entre autres, du contenu de la mémoire et du filtrage. Une destination pleine ou inaccessible peut empêcher la sauvegarde, même si la réservation est correctement configurée.

Même une installation préparée ne garantit pas l'obtention d'un dump exploitable. Un « oops » ne déclenche pas nécessairement une « panic » ; en cas de coupure totale de courant, le noyau de capture ne peut plus fonctionner. De même, une grave défaillance matérielle peut empêcher son démarrage ou l'écriture de l'image. La capture et la cible doivent donc être considérées indépendamment de la cause réelle de l'erreur.

Quels fichiers sont pris en compte pour l'analyse ?

Pour l'analyse, le fichier de vidage n'est pas le seul élément important. Dans la mesure du possible, conservez également les fichiers de noyau et les journaux associés afin de pouvoir recouper l'état au moment du plantage avec les messages et les modifications. Le tableau suivant distingue l'image mémoire proprement dite des fichiers auxiliaires qui permettent son analyse.

C'est particulièrement important vmlinux correspondant: L'architecture et la version exacte du noyau doivent correspondre à celles du noyau qui a planté. Le noyau qui s'exécute après le redémarrage peut être différent. La sortie de uname -r sur le serveur qui vient d'être redémarré ne suffit donc pas pour sélectionner le fichier correspondant à l'ancienne sauvegarde.

Utilisez également une version de crash compatible avec le noyau et le format de vidage. Si des pilotes externes ou supplémentaires sont concernés, veillez à fournir également leurs fichiers de module correspondants et leurs informations de débogage. Si des symboles manquent ou si des pages mémoire nécessaires ont été filtrées, l'analyse peut être limitée ; ces lacunes doivent être mentionnées dans la documentation du rapport.

Un fichier vmcore peut contenir des informations confidentielles issues de la mémoire vive. Il convient donc d'en restreindre l'accès, de sécuriser son transfert et de définir des délais de conservation et de suppression. Avant de transmettre un dump ou des journaux complémentaires à un service d'assistance, vérifiez les autorisations requises et l'étendue autorisée de ces données.

Préparer kdump sur le serveur

Il faut commencer par déterminer la distribution, la version et l'architecture du serveur. Consulte la documentation correspondante pour savoir quels paquets sont nécessaires pour kdump et le chargement du noyau de capture, ainsi que la manière de configurer le service. Les instructions relatives aux différentes distributions ne sont pas interchangeables : les noms de paquets, la configuration de démarrage et les outils de vérification peuvent varier.

La préparation comprend le choix de la Réservation de mémoire via le paramètre de démarrage crashkernel. Choisissez la taille et, le cas échéant, d'autres paramètres conformément aux spécifications de la plateforme et du matériel concernés. L'espace mémoire réservé n'est pas disponible pour le système fonctionnant normalement ; une indication de taille universelle serait donc tout aussi peu utile qu'une reprise non vérifiée à partir d'un autre serveur.

Une fois la configuration de démarrage spécifique à la plate-forme effectuée et, le cas échéant, le redémarrage effectué, la commande shell suivante affiche les paramètres du noyau actuellement en cours d'exécution. Recherchez dans la sortie crashkernel. Une entrée indique le paramètre transmis, mais ne prouve ni que le noyau de capture a été chargé, ni que la sauvegarde a abouti.

cat /proc/cmdline

Sous RHEL 9, tu peux également vérifier l'état à l'aide de la commande suivante dans le shell. Sur d'autres distributions, utilise la procédure de vérification décrite dans la documentation correspondante. Un résultat positif Message d'état C'est un indicateur important de l'état de fonctionnement, mais cela ne remplace pas un test contrôlé de l'ensemble du circuit de sécurité.

kdumpctl status

Vérifie également si la cible prévue et les pilotes nécessaires sont disponibles dans le système de capture. Note les paramètres sélectionnés et la date du contrôle afin de pouvoir les réévaluer après des modifications du noyau ou de l'infrastructure. Avant la mise en production, tu dois vérifier les paramètres concrets pour la plate-forme cible réellement utilisée.

Sélectionner la destination de la sauvegarde et l'étendue de la sauvegarde

Le Objectif de sauvegarde doit être accessible pendant la collecte et disposer d'un espace libre suffisant. Une destination locale évite de dépendre d'une connexion réseau, mais nécessite de l'espace de stockage disponible sur le serveur. Prévoyez également que plusieurs sauvegardes et fichiers de diagnostic associés peuvent occuper de l'espace.

RHEL 9 prend en charge non seulement les cibles locales, mais aussi les cibles réseau via NFS ou SSH. Cela permet de stocker le fichier séparément du serveur concerné ; pour cela, le réseau, le poste distant et les composants nécessaires doivent fonctionner correctement dans le système de capture. Vérifie les restrictions propres à la configuration RHEL concernée, au lieu de considérer que l'accessibilité en fonctionnement normal est identique à celle du système de capture.

Avec makedumpfile Il est possible de compresser l'image et de la filtrer en fonction de zones de mémoire sélectionnées. Filtrage Cela permet d'économiser de l'espace de stockage et de réduire le volume de transfert, mais supprime des pages qui pourraient s'avérer nécessaires pour une analyse ultérieure. Adaptez donc l'étendue de la sauvegarde au diagnostic prévu et documentez les filtres utilisés ; le fichier le plus petit n'est pas forcément le plus utile.

Un fichier vmcore peut contenir des informations confidentielles issues de la mémoire vive. Il convient donc d'en limiter l'accès, d'en sécuriser le transfert et de définir la durée de conservation des fichiers ainsi que le moment où ils doivent être supprimés. Avant toute transmission à un service d'assistance, vérifiez que l'autorisation nécessaire a bien été obtenue ; cela vaut également pour les copies stockées séparément.

Ouvrir un fichier vmcore existant avec crash

Pour l'analyse ultérieure, tu as besoin du fichier vmcore existant, qui doit correspondre à la version du noyau qui a planté et à l'architecture vmlinux avec informations de débogage ainsi qu'une version de crash compatible avec le noyau et le format de vidage. Le noyau en cours d'exécution après un redémarrage peut être différent ; l'affichage de sa version ne permet donc pas à lui seul d'identifier de manière fiable la version qui a planté.

La commande schématique suivante doit être exécutée dans le shell standard du système d'analyse. Remplacez les deux chemins d'accès par ceux des fichiers réels. Cette commande ouvre une image existante pour l'analyser ; elle ne génère pas de dump et ne configure pas non plus kdump.

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

Une fois que tu auras pris tes marques, tu travailleras sur invite de crash, et non plus dans le shell standard. Là, la commande affiche log les messages du noyau disponibles. Commencez par rechercher le message de panique et les messages qui l'entourent ; ces messages peuvent fournir un point de départ, mais ne décrivent pas nécessairement la cause complète.

Avec bt tu examines la pile du contexte d'analyse actuel ; bt -a affiche les piles des tâches actives sur les processeurs. Comparez les chaînes d'appel avec les messages, plutôt que de considérer une seule trame comme preuve de la cause du problème. Selon l'état et l'étendue du vidage, certaines informations peuvent manquer.

Dans la même invite, vous pouvez utiliser ps dans la vue d'ensemble des tâches ; kmem -i fournit des informations générales sur la mémoire. Cet instantané ne permet à lui seul ni de prouver l'existence d'une fuite de mémoire, ni d'en identifier la cause. Si un module concerné doit faire l'objet d'une analyse plus approfondie, des fichiers de module et des informations de débogage appropriés peuvent également s'avérer nécessaires.

Classer les piles et les notes de mémoire

Si une erreur « Panic » survient après une modification de pilote, note tout d'abord le moment où elle s'est produite, la version du noyau qui a planté et les modules concernés. Compare ces informations avec le journal des modifications : le pilote a-t-il été mis à jour seul ou un nouveau noyau a-t-il été installé en même temps ? Cela te permettra de déterminer quelles modifications sont pertinentes pour l'analyse.

Lis ensuite avec log les messages du noyau disponibles et analyse-les à l'aide de bt la pile du contexte d'analyse actuel. bt -a complète la vue des tâches actives des processeurs. Notez, outre le texte du « panic », les messages qui ont précédé celui-ci ; ils peuvent fournir le contexte d'une erreur qui apparaîtra ultérieurement.

A Cadre de commande La présence d'un problème dans la pile constitue un indice, mais ne prouve pas la culpabilité. Par exemple, une corruption de mémoire antérieure peut ne se manifester qu'au niveau d'une fonction de pilote. Vérifie donc si les messages, les modules impliqués et le déroulement des événements concordent avant de conclure qu'une modification en est la cause.

En cas de suspicion de stockage, kmem -i un aperçu des informations relatives à la mémoire, dans la mesure où le dump et l'outil les fournissent. Examinez ces valeurs en parallèle avec les messages du noyau. Une valeur isolée ne permet ni de confirmer une fuite de mémoire ni d'en identifier la cause ; de plus, certaines pages de mémoire peuvent manquer en raison du filtrage.

Pour déterminer si la consommation augmente au fil du temps, tu as besoin de séries chronologiques complémentaires. Une analyse distincte de la charge du processeur permet de Profilage du processeur à l'aide de l'outil Linux Perf aider. Ces mesures complètent le crash dump, mais ne remplacent pas l'état qui y est consigné au moment du plantage.

S'il n'y a pas de fichier vmcore exploitable

Après un blocage suivi d'un redémarrage, il faut d'abord vérifier si un « Panic » s'est effectivement produit et si un fichier vmcore a été sauvegardé. Un simple redémarrage ne suffit pas à prouver ces deux éléments. Recherchez les messages correspondant à ce moment-là et vérifiez l'emplacement de stockage configuré avant de conclure à une erreur spécifique en vous basant uniquement sur l'absence d'un fichier.

Examine la Chaîne de saisie Par ailleurs : un noyau de capture était-il chargé sur la machine concernée, et l'événement était-il de nature à déclencher kdump ? Tous les « oops » n'entraînent pas nécessairement une « panic ». Une coupure totale d'alimentation ou une grave défaillance matérielle peut également empêcher le noyau de capture de démarrer ou d'écrire des données.

Vérifiez ensuite la cible de sauvegarde : était-elle accessible, y avait-il suffisamment d'espace disponible et le système de capture contenait-il les pilotes et composants nécessaires ? Dans le cas d'une cible réseau, la connexion et le poste distant constituent des dépendances supplémentaires. Sous RHEL, le fichier kexec-dmesg.log Fournir des informations sur la phase de saisie, si celle-ci a été créée et enregistrée.

En l'absence de fichier de vidage exploitable, les journaux antérieurs ou les messages persistants de la console et du noyau constituent des alternatives importantes. Ces sources ne fournissent toutefois pas d'image mémoire complète ; l'état perdu ne peut pas être reconstitué a posteriori à l'aide de kdump.

Si des messages ou d'autres observations laissent présager des problèmes de réseau, une analyse complémentaire peut être effectuée Analyse de l'utilisation des SoftIRQ sous Linux aider à comprendre le traitement des paquets. Elle répond à une question différente de celle de la vérification de la destination du dump et ne prouve en soi ni la présence d'une panique, ni la cause d'un échec de la sauvegarde.

Tester la saisie et valider les résultats

Choisissez l'étendue de la sauvegarde en fonction de la question diagnostique prévue et des ressources disponibles. La compression et le filtrage permettent d'économiser de l'espace de stockage et de réduire le volume de données transférées ; toutefois, les pages mémoire supprimées ne seront plus disponibles pour des analyses ultérieures. Documentez ce choix afin que l'on puisse identifier, lors de l'analyse, les données qui pourraient manquer.

Un fichier vmcore peut contenir des informations confidentielles provenant de la mémoire. Tu dois donc définir les règles d'accès, les modalités de transfert sécurisé et la durée de conservation, ainsi que le stockage des fichiers de débogage correspondants. Avant de transmettre ces données à un service d'assistance, tu dois t'assurer que l'autorisation nécessaire a été obtenue et clarifier la manière dont les données seront traitées.

Vérifiez à nouveau la configuration si le noyau, les pilotes, la configuration de démarrage ou l'infrastructure de sauvegarde changent. Cela inclut le noyau de capture chargé et l'accessibilité de la cible sélectionnée. Un message d'état positif est utile, mais il n'indique pas à lui seul si, dans les conditions actuelles, un dump analysable est effectivement généré.

Avertissement : Un test de bout en bout contrôlé provoque délibérément un plantage et peut entraîner des redémarrages et une perte de données. Ne l'effectuez que dans un environnement de test validé ou lors d'une fenêtre de maintenance prévue à cet effet, avec une sauvegarde des données. Clarifiez au préalable les responsabilités, les répercussions et la procédure de redémarrage ; aucune commande de déclenchement n'est délibérément fournie à cet effet.

Un indicateur significatif Test de bout en bout Ne vous arrêtez pas à la vérification du statut : vérifiez si le fichier est bien arrivé à la destination prévue et s'il peut être ouvert avec les fichiers correspondant à la version enregistrée. Lors du débogage du serveur, consignez ensuite les constatations, les données manquantes, les incertitudes et les prochaines étapes de vérification. Veillez à bien distinguer les indices observés des causes non encore confirmées.