Kdump est une fonctionnalité du noyau qui est utilisée pour capturer les vidages sur incident lorsque le système ou le noyau tombe en panne. Pour activer kdump, nous devons réserver une partie de la RAM physique qui sera utilisée pour exécuter le noyau kdump en cas de panique ou de plantage du noyau.
Lorsqu'un plantage du noyau ou une panique du noyau se produit, le noyau en cours d'exécution exécute 'kexec(kdump kernel) ' et il charge le noyau kdump à partir de la mémoire de réserve, puis le contenu de la RAM et Swap est copié dans le fichier vmcore sur le disque local ou sur le disque distant et enfin redémarre la boîte.
En analysant les vidages sur incident, nous pouvons trouver la raison ou le cas racine de la défaillance du système. Si votre système d'exploitation est pris en charge, vous pouvez partager les vidages sur incident avec le fournisseur pour analyse.
Dans cet article, nous allons montrer comment activer kdump sur RHEL 7 et CentOS 7
Étape 1 Installez "kexec-tools" à l'aide de la commande yum
Utilisez la commande yum ci-dessous pour installer le package "kexec-tools" au cas où il ne serait pas installé.
[[email protected] ~]# yum install kexec-tools
Étape :2 Mettez à jour le fichier GRUB2 pour réserver de la mémoire pour le noyau Kdump
Modifiez le fichier GRUB2 (/etc/default/grub ), ajoutez le paramètre 'crashkernel=
GRUB_CMDLINE_LINUX="rd.lvm.lv=centos/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=centos/root crashkernel=128M vconsole.keymap=us rhgb quiet"
Exécutez la commande ci-dessous pour régénérer la configuration grub2.
[[email protected] ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
En cas de micrologiciel UEFI, utilisez la commande ci-dessous
[[email protected] ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
La commande ci-dessus informera le chargeur de démarrage de réserver 128 Mo de RAM après le redémarrage.
Redémarrez la box maintenant en utilisant la commande ci-dessous :
[[email protected] ~]# shutdown -r now
Étape 3 Mettre à jour l'emplacement de vidage et l'action par défaut dans le fichier (/etc/kdump.conf)
Pour stocker le vidage sur incident ou le fichier vmcore sur un système de fichiers local, modifiez le fichier '/etc/kdump.conf ' et spécifiez l'emplacement selon votre configuration. Dans mon cas, j'utilise un système de fichiers local séparé ( /var/crash ). Il est recommandé que la taille du système de fichiers soit équivalente à la taille de la RAM de votre système ou que le système de fichiers ait un espace libre équivalent à la taille de la RAM. Kdump permet de compresser les données de vidage en utilisant l'option 'core collector' (core_collector makedumpfile -c ) où -c est utilisé pour la compression.
Dans le cas où kdump ne parvient pas à stocker le fichier de vidage à l'emplacement spécifié, l'action par défaut sera effectuée, ce qui est mentionné dans la directive par défaut. Dans mon cas, l'action par défaut est le redémarrage.
Mettez à jour les trois directives ci-dessous dans le fichier kdump.conf.
[[email protected] ~]# vi /etc/kdump.conf path /var/crash core_collector makedumpfile -c default reboot
Différentes options pour stocker le dump :
Étape : 4 Démarrez et activez le service kdump
[[email protected] ~]# systemctl start kdump.service [[email protected] ~]# systemctl enable kdump.service [[email protected] ~]#
Étape 5 :Testez maintenant Kdump en plantant manuellement le système
Avant de planter votre système, veuillez vérifier si le service kdump est en cours d'exécution ou non en utilisant la commande ci-dessous.
[[email protected] crash]# systemctl is-active kdump.service [[email protected] crash]# service kdump status
Pour tester notre configuration kdump, nous allons planter manuellement notre système avec les commandes ci-dessous.
[[email protected] ~]# echo 1 > /proc/sys/kernel/sysrq ; echo c > /proc/sysrq-trigger
Cela créera un fichier de vidage sur incident (vmcore ) sous '/var/crash ‘ système de fichiers.
[[email protected] ~]# ls -lR /var/crash /var/crash: total 0 drwxr-xr-x. 2 root root 42 Mar 4 03:02 127.0.0.1-2016-03-04-03:02:17 /var/crash/127.0.0.1-2016-03-04-03:02:17: total 135924 -rw-------. 1 root root 139147524 Mar 4 03:02 vmcore -rw-r--r--. 1 root root 35640 Mar 4 03:02 vmcore-dmesg.txt [[email protected] ~]#
Étape : 6 Utilisez la commande "crash" pour analyser et déboguer les vidages sur incident
Crash est l'utilitaire ou la commande permettant de déboguer et d'analyser le vidage sur incident ou le fichier vmcore.
Pour utiliser le crash, assurez-vous que deux packages sont installés :'crash &kernel-debuginfo ‘
[[email protected] ~]# yum install crash
Pour installer le package "kernel-debuginfo", activez d'abord le dépôt de débogage. Modifiez le fichier de dépôt /etc/yum.repos.d/CentOS-Debuginfo.repo
changer 'enbled=0' en 'enabled=1'
[[email protected] ~]# yum install kernel-debuginfo
Une fois que le kernel-debuginfo est installé, essayez d'exécuter la commande ci-dessous, cela nous donnera une invite de plantage où nous pouvons exécuter des commandes pour trouver des informations sur le processus, la liste des fichiers ouverts lorsque le système s'est planté.
[[email protected] ~]# crash /var/crash/127.0.0.1-2016-03-04-14\:20\:06/vmcore /usr/lib/debug/lib/modules/`uname -r`/vmlinux crash>
Tapez 'ps ' pour répertorier les processus en cours d'exécution lorsque le système s'est écrasé.
crash> ps
Pour afficher les fichiers qui étaient ouverts lorsque le système a planté, tapez la commande "fichiers" à l'invite de plantage.
crash> files PID: 5577 TASK: ffff88007b44f300 CPU: 0 COMMAND: "bash" ROOT: / CWD: /root FD FILE DENTRY INODE TYPE PATH 0 ffff880036b85000 ffff8800796fa540 ffff88007966f4d0 CHR /dev/pts/0 1 ffff880036b73900 ffff880068c409c0 ffff8800794a8d10 REG /proc/sysrq-trigger 2 ffff880036b85000 ffff8800796fa540 ffff88007966f4d0 CHR /dev/pts/0 10 ffff880036b85000 ffff8800796fa540 ffff88007966f4d0 CHR /dev/pts/0 255 ffff880036b85000 ffff8800796fa540 ffff88007966f4d0 CHR /dev/pts/0 crash>
Tapez la commande "sys" pour répertorier les informations système en cas de plantage.
crash> sys KERNEL: /usr/lib/debug/lib/modules/3.10.0-327.10.1.el7.x86_64/vmlinux DUMPFILE: /var/crash/127.0.0.1-2016-03-04-14:20:06/vmcore CPUS: 1 DATE: Fri Mar 4 14:20:01 2016 UPTIME: 00:02:00 LOAD AVERAGE: 0.75, 0.48, 0.19 TASKS: 115 NODENAME: cloud.linuxtechi.com RELEASE: 3.10.0-327.10.1.el7.x86_64 VERSION: #1 SMP Tue Feb 16 17:03:50 UTC 2016 MACHINE: x86_64 (2388 Mhz) MEMORY: 2 GB PANIC: "SysRq : Trigger a crash" crash>
Pour obtenir de l'aide sur n'importe quelle commande à l'invite de plantage, tapez 'help
Voilà qui conclut l'article, n'hésitez pas à le partager si vous avez apprécié.
Lire aussi : Comment installer ownCloud sur CentOS 7