¿Qué es el soporte inicial de kdump?
En versiones anteriores de CentOS/RHEL (5/6/7), el servicio kdump comenzaba muy tarde en la secuencia de arranque. Por lo tanto, la información de fallas tempranas se pierde durante el arranque. A partir de CentOS/RHEL 8, se introdujo un nuevo mecanismo de kdump llamado "soporte de kdump temprano" para abordar este problema. Early Kdump almacena vmlinuz e initramfs del kernel bloqueado dentro de los initramfs del kernel de arranque y los carga directamente en la memoria reservada (crashkernel) durante la etapa inicial de arranque.
El paquete "kexec-tools" ahora tiene 2 módulos adicionales para cargar el kernel de bloqueo e initramfs lo antes posible durante la secuencia de arranque para capturar el volcado de bloqueo del kernel del kernel de arranque.
/usr/lib/dracut/modules.d/99earlykdump/early-kdump.sh /usr/lib/dracut/modules.d/99earlykdump/module-setup.sh
# dracut --list-modules | grep earlykdump earlykdump
De forma predeterminada, el soporte temprano de kdump está deshabilitado y tenemos que habilitarlo manualmente. También es compatible con todos los destinos de volcado y parámetros de configuración admitidos por las configuraciones anteriores de kdump en CentOS/RHEL 5,6,7.
Configurar el servicio kdump
1. Consulte la publicación de configuración de kdump a continuación para configurar kdump y asegurarse de que el servicio kdump esté en estado de ejecución.
CentOS/RHEL 7:Cómo configurar kdump# systemctl enable --now kdump.service
# systemctl status kdump.service ● kdump.service - Crash recovery kernel arming Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled) Active: active (exited) since Mon 2019-08-19 23:42:11 IST; 16h ago Main PID: 1255 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 26213) Memory: 0B CGroup: /system.slice/kdump.service Aug 19 23:42:09systemd[1]: Starting Crash recovery kernel arming... Aug 19 23:42:11 kdumpctl[1255]: Kdump already running: [WARNING] Aug 19 23:42:11 systemd[1]: Started Crash recovery kernel arming.
2. Enumere los módulos de volcado temprano que están disponibles en el sistema
# dracut --list-modules | grep earlykdump earlykdump
3. Agregue el parámetro rd.earlykdump a kernelopts línea en /boot/grub2/grubenv archivo:
# cat /boot/grub2/grubenv # GRUB Environment Block saved_entry=4eb68bf18e86437d9c957ff4863a3288-4.18.0-80.el8.x86_64 kernelopts=root=/dev/mapper/ol-root ro crashkernel=auto resume=/dev/mapper/ol-swap rd.lvm.lv=ol/root rd.lvm.lv=ol/swap rd.earlykdump boot_success=0 ################################################################################################### ################################################################################################### ###################################################################################################
Recrear iniramfs
1. Ahora, el siguiente paso es volver a crear initramfs para agregar módulos de volcado anticipado:
# lsinitrd | grep -i early
# dracut -f --add earlykdump
Por ejemplo:
# lsinitrd |grep -i early Arguments: -f --add 'earlykdump' earlykdump -rwxr-xr-x 1 root root 1940 Jun 17 10:29 usr/lib/dracut/hooks/cmdline/00-early-kdump.sh
2. Reinicie el cuadro para cargar los cambios
# reboot
3. Una vez que el servidor vuelva a estar en línea, verifique el estado de early-kdump:
# journalctl -x |grep -i early-kdump Aug 20 16:08:09 [HOSTNAME] dracut-cmdline[196]: early-kdump is enabled. Aug 20 16:08:10 [HOSTNAME] dracut-cmdline[196]: kexec: loaded early-kdump kernel
Prueba de volcado temprano
Ahora probemos el volcado temprano usando archivos de unidad systemd personalizados y hagamos que el pánico se cuelgue usando SysRq.
1. Cree un nombre de archivo de unidad /etc/systemd/system/test_early_kdump.service .
# touch /etc/systemd/system/test_early_kdump.service
2. Proporcione los permisos apropiados:
# chmod 664 /etc/systemd/system/test_early_kdump.service
El archivo de la unidad debe tener el siguiente aspecto:
# cat /etc/systemd/system/test_early_kdump.service [Unit] Description=test_early_kdump Service Before=kdump.service [Service] ExecStart=/usr/local/test_early_kdump.sh Type=simple [Install] WantedBy=default.target
3. Luego cree otro script /usr/local/test_early_kdump.sh archivo para pasar el comando de bloqueo de sysrq:
# cat /usr/local/test_early_kdump.sh #!/bin/bash /usr/bin/echo c > /proc/sysrq-trigger
4. Proporcione permiso ejecutable para el script:
# chmod +x /usr/local/test_early_kdump.sh
5. Vuelva a cargar el demonio systemd:
# systemctl daemon-reloadIMPORTANTE :No inicie el servicio test_early_kdump.service (fallo de prueba), de lo contrario, el sistema fallará inmediatamente.
6. Habilite este servicio test_early_kdump en el nivel de arranque:
# systemctl enable test_early_kdump.service
7. Reinicie el sistema:
# rebootNota :Mientras el sistema se inicia según el script de prueba personalizado, provocará un bloqueo y seguirá reiniciando.
8. Deshabilite la unidad personalizada y los archivos de script y elimínelos después de probarlos. Inicie el sistema en modo de rescate usando 'systemd.unit=rescue.target ' y deshabilite el servicio 'test_early_kdump' en el momento del arranque.
# systemctl disable test_early_kdump.service
El comando anterior desactiva el archivo de unidad personalizado. La próxima vez que el sistema arranque normalmente.
Cómo iniciar en modo de rescate o modo de emergencia a través de Systemd en CentOS/RHEL 7 y 89. Elimine los archivos de la unidad personalizada y el archivo de secuencia de comandos de bloqueo cuando se complete el bloqueo de PRUEBA:
# rm /etc/systemd/system/test_edump.service rm: remove regular file '/etc/systemd/system/test_edump.service'? y
# rm /usr/local/test_early_kdump.sh
10. Compruebe el /var/crash/ carpeta según kdump.conf (ruta /var/crash) mencionada para vmcore:
# ls -l /var/crash/127.0.0.1-2019-08-20-17:09:23 total 56648 -rw-------. 1 root root 57959829 Aug 20 17:09 vmcore -rw-r--r--. 1 root root 41452 Aug 20 17:09 vmcore-dmesg.txt