Collecte des vidages sur incident à l'aide de l'utilitaire Kdump

Si vous utilisez une image de plate-forme Oracle Linux, Kdump est installé et entièrement ou partiellement configuré. Vous pouvez modifier la quantité de mémoire réservée sur le noyau pour enregistrer le vidage sur incident, également appelée réservation de mémoire crashkernel. Dans Oracle Linux 8 et les versions antérieures, la réservation de mémoire par défaut est définie pour s'ajuster automatiquement : GRUB_CMDLINE_LINUX="crashkernel=auto". Cependant, crashkernel=auto n'est pas pris en charge pour Oracle Linux 9. Vous devez donc définir une quantité spécifique de mémoire réservée à l'aide du paramètre crashkernel.

Pour définir la réservation de mémoire pour un vidage sur incident :

1. A partir d'une ligne de commande, à l'aide des privilèges d'administration, connectez-vous à l'instance à l'aide de SSH.
2. Modifiez le fichier /etc/default/grub pour définir la mémoire réservée. Par exemple :
   • Définissez la réserve de mémoire sur 64 Mo, par exemple :

     GRUB_CMDLINE_LINUX="crashkernel=64MB"

   • Définissez la quantité de mémoire réservée en tant que variable à l'aide de la syntaxe crashkernel=<range1>:<size1>,<range2>:<size2>. Par exemple :

     GRUB_CMDLINE_LINUX="crashkernel=512M-2G:64M,2G-:128M"

   • Définissez une valeur de décalage pour la mémoire réservée. Etant donné que la réservation crashkernel a lieu au début du processus d'initialisation, certains systèmes nécessitent que vous réserviez de la mémoire avec un certain décalage fixe. Lorsqu'un décalage fixe est spécifié, la mémoire réservée commence à ce point. Par exemple, pour réserver 128 Mo de mémoire, à partir de 16 Mo :

     GRUB_CMDLINE_LINUX="crashkernel=128M@16M"

3. Enregistrez les modifications et actualisez la configuration grub :

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

4. Redémarrez l'instance pour appliquer les modifications.

A l'aide de /etc/kdump.conf, vous pouvez modifier l'emplacement dans lequel les fichiers de vidage sur incident sont enregistrés, les transférer via SSH ou les exporter vers un partage réseau.

1. A partir d'une ligne de commande, à l'aide des privilèges d'administration, connectez-vous à l'instance à l'aide de SSH.
2. Modifiez le fichier de configuration dans le fichier /etc/kdump.conf et enlevez le caractère de commentaire # au début de chaque ligne à activer.
   • Modifiez le répertoire par défaut (/var/oled/crash) des fichiers de vidage sur incident, par exemple :

     path /usr/local/<cores>

   • Transférez les fichiers de vidage sur incident via une connexion shell sécurisée, par exemple :

     ssh <user@example.com>
     sshkey /root/.ssh/<mykey>

   • Définissez les fichiers de vidage sur incident à exporter vers un partage réseau compatible, par exemple :

     nfs <example.com>:/<output>

   Pour plus d'informations, reportez-vous au fichier kdump.conf.5 dans l'archive /usr/share/man/man5/kdump.conf.5.gz.

3. Lorsque vous avez terminé, enregistrez les modifications et redémarrez le service kdump.

   sudo systemctl restart kdump.service 

4. Redémarrez l'instance pour appliquer les modifications.

Par défaut, si Kdump ne parvient pas à envoyer son résultat aux emplacements de sortie configurés, il réinitialise le serveur. Cette action supprime toutes les données collectées pour le vidage. Pour éviter ce résultat, modifiez la configuration de Kdump.

1. A partir d'une ligne de commande, à l'aide des privilèges d'administration, connectez-vous à l'instance à l'aide de SSH.
2. Modifiez /etc/kdump.conf pour annuler la mise en commentaire et modifiez la valeur default dans le fichier comme suit :

   default dump_to_rootfs

   L'option dump_to_rootfs tente d'enregistrer le résultat dans un répertoire local, ce qui peut être utile si un partage réseau est inaccessible. Vous pouvez utiliser shell à la place pour copier les données manuellement à partir de la ligne de commande.

   Remarque
   
   

   Les options poweroff, restart et halt sont également valides pour l'état d'échec kdump par défaut. Toutefois, l'exécution de ces actions entraîne la perte des données collectées si ces actions sont effectuées. Pour plus d'informations, reportez-vous au fichier kdump.conf.5 dans l'archive /usr/share/man/man5/kdump.conf.5.gz.

3. Lorsque vous avez terminé, enregistrez les modifications et redémarrez le service kdump.

   sudo systemctl restart kdump.service

4. Redémarrez l'instance pour appliquer les modifications.

Testez la configuration du vidage sur incident en plantant le noyau qui déclenche le service pour collecter un vidage sur incident. Passez ensuite en revue le vidage sur incident.

1. A partir d'une ligne de commande, à l'aide des privilèges d'administration, connectez-vous à l'instance à l'aide de SSH.
2. Assurez-vous que Kdump est en cours d'exécution :

   systemctl is-active kdump

3. Lancez la panne à partir de la console ou de la ligne de commande :

   echo 1 > /proc/sys/kernel/sysrq
   echo c > /proc/sysrq-trigger

   Cela force le noyau à planter et les fichiers dump sont copiés dans le répertoire /var/oled/crash/<ip-address>-<YYYY-MM-DD>-<HH:MM:SS>, par défaut, ou à l'emplacement que vous avez sélectionné dans la configuration.
4. Redémarrer l'instance.
5. Reconnectez-vous à l'instance à l'aide de SSH et vérifiez les fichiers de vidage sur incident dans /var/oled/crash/<ip-address>-<YYYY-MM-DD>-<HH:MM:SS> :
   • Le tampon de messages du noyau contient les informations les plus essentielles sur la panne du système et est toujours vidé en premier dans le fichier vmcore-dmesg.txt. Cela est utile en cas d'échec d'une tentative d'obtention du fichier vmcore complet, par exemple en raison d'un manque d'espace sur l'emplacement cible.
   • Lorsque l'outil kexec s'initialise dans le second noyau et capture le contenu de la mémoire du noyau en panne, il écrit également dans le fichier kexec-dmes.log afin que vous puissiez suivre le processus. Par exemple, à la fin du fichier, vous pouvez voir le processus d'enregistrement du vidage sur incident :

     ...
     Feb 07 16:28:19 linux9 systemd[1]: Starting Kdump Vmcore Save Service...
     Feb 07 16:28:19 linux9 kdump[504]: Kdump is using the default log level(3).
     Feb 07 16:28:19 linux9 kdump[541]: saving to /kdumproot/var/oled/crash/127.0.0.1-2025-02-07-16:28:19/
     Feb 07 16:28:19 linux9 kdump[546]: saving vmcore-dmesg.txt to /kdumproot/var/oled/crash/127.0.0.1-2025-02-07-16:28:19/
     Feb 07 16:28:19 linux9 kdump[552]: saving vmcore-dmesg.txt complete
     Feb 07 16:28:19 linux9 kdump[554]: saving vmcore
     Feb 07 16:28:21 linux9 kdump.sh[555]: 
     Checking for memory holes                         : [  0.0 %] /                  
     ...
     Copying data                                      : [100.0 %] \           eta: 0s
     Feb 07 16:28:21 linux9 kdump.sh[555]: The dumpfile is saved to /kdumproot/var/oled/crash/127.0.0.1-2025-02-07-16:28:19//vmcore-incomplete.
     Feb 07 16:28:21 linux9 kdump.sh[555]: makedumpfile Completed.
     Feb 07 16:28:21 linux9 kdump[559]: saving vmcore complete
     Feb 07 16:28:21 linux9 kdump[561]: saving the /run/initramfs/kexec-dmesg.log to /kdumproot/var/oled/crash/127.0.0.1-2025-02-07-16:28:19//

   • Le fichier vmcore contient les informations de vidage sur incident. Pour analyser le vidage sur incident, vous avez besoin d'un utilitaire capable de lire le format de fichier vmcore. Pour plus d'informations sur l'utilisation de l'utilitaire crash, reportez-vous à Analyse des vidages sur incident.

Vous pouvez utiliser l'utilitaire crash pour analyser les vidages sur incident collectés par Kdump. Dans les images de plate-forme Oracle Linux, crash est installé par défaut. Pour les autres instances Linux, utilisez la ligne de commande pour l'installer : sudo dnf install crash.