Collecte des vidages accidentels à l'aide de l'utilitaire Kdump

Sur les images de plate-forme Oracle Linux, Kdump est installé et entièrement configuré ou partiellement configuré par défaut. Vous pouvez modifier la quantité de mémoire réservée dans le noyau pour enregistrer le vidage sur incident, également appelé réservation de mémoire du noyau de mémoire sur incident. Dans Oracle Linux 8 et versions antérieures, la réservation de mémoire par défaut est réglée pour s'ajuster automatiquement : GRUB_CMDLINE_LINUX="crashkernel=auto". Toutefois, crashkernel=auto n'est pas pris en charge sur Oracle Linux 9 ou une version plus récente. 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. À 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 :
   • Réglez la réserve de mémoire à 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. Comme la réservation crashkernel a lieu au début du processus de démarrage, certains systèmes exigent 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.

À 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 au moyen de SSH ou les exporter vers un partage de réseau.

1. À 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 supprimez 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, voir le 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 redémarre le serveur. Cette action supprime toutes les données qui ont été collectées pour le vidage. Pour empêcher ce résultat, modifiez la configuration Kdump.

1. À 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.

   Note
   
   

   Les options poweroff, restart et halt sont également valides pour l'état d'échec kdump par défaut. Toutefois, si vous effectuez ces actions, vous perdrez les données collectées. Pour plus d'informations, voir le 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 Kdump en bloquant le noyau qui déclenche la collecte d'un vidage sur incident par le service. Ensuite, vérifiez le vidage sur incident.

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

   systemctl is-active kdump

3. Démarrez 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 à se bloquer et les fichiers de vidage 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> :
   • La mémoire tampon des messages du noyau inclut les informations les plus essentielles sur la panne du système et elle est toujours vidée d'abord dans le fichier vmcore-dmesg.txt. Cette fonction est utile en cas d'échec d'une tentative d'obtention du fichier vmcore complet, par exemple en raison d'un manque d'espace dans l'emplacement cible.
   • Lorsque l'outil kexec démarre dans le deuxième noyau et capture le contenu de la mémoire du noyau écrasé, 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. Voir Analyse des vidages d'incident pour plus d'informations sur l'utilisation de l'utilitaire crash.

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.