Cómo guardar y analizar volcados de memoria de Linux con kdump

Lo que registra «kdump» cuando se produce un fallo del núcleo

kdump prepara la copia de seguridad de una imagen de memoria del núcleo de Linux antes de que se produzca un fallo del sistema. Para ello, al iniciar el núcleo normal se reserva un área de memoria. En esta área se almacena un Kernel de captura cargado, que puede iniciarse mediante kexec en caso de que se produzca un fallo adecuado.

El núcleo de captura se ejecuta independientemente del núcleo del sistema que se ha bloqueado y accede a su imagen de memoria a través de /proc/vmcore. Puede guardar esta imagen en una ubicación configurada. El archivo guardado suele denominarse «vmcore»; que contenga todas las áreas de memoria originales depende, entre otras cosas, del filtrado seleccionado.

Las funciones están separadas: kdump registra y guarda el estado, mientras que el programa accidente A continuación, se analiza un volcado existente. Esto permite, por ejemplo, examinar los mensajes del núcleo y las colas de tareas. Un volcado es una instantánea y no proporciona automáticamente el historial completo del error.

Un «oops» del núcleo no es lo mismo que un «panic» del núcleo: un «oops» puede producirse sin que el sistema entre inmediatamente en estado de «panic». Por eso, no todos los fallos del núcleo dan lugar a un volcado kdump. Por el contrario, un volcado de memoria (core dump) de una aplicación se refiere al estado de un proceso y no es un vmcore del núcleo.

Esta preparación es fundamental para el análisis posterior. Si en el momento del fallo no se había preparado ningún kernel de captura o no se había guardado ninguna imagen, kdump no podrá reconstruir posteriormente el estado de la memoria perdido. En ese caso, los registros disponibles y otros datos de diagnóstico conservados tras el reinicio servirán como punto de partida.

Requisitos y límites del registro

Aclara primero la distribución, la versión y la arquitectura del servidor. De ello dependen los nombres de los paquetes, el control de servicios, la configuración de arranque y los destinos de almacenamiento compatibles. Para la configuración, utiliza la documentación específica de esta plataforma, en lugar de combinar comandos de diferentes distribuciones; además, el hardware y los controladores instalados también influyen en los requisitos.

El parámetro de arranque crashkernel establece la Reserva de memoria para el registro de fallos. Este espacio no está disponible para el funcionamiento normal. No es fiable fijar un tamaño fijo: guíate por las especificaciones relativas a la distribución, la arquitectura y el equipamiento concreto, y ten en cuenta las necesidades de almacenamiento del sistema de captura.

La memoria reservada por sí sola no es suficiente. El núcleo de captura debe estar cargado y poder acceder al destino configurado. Para ello, los controladores y componentes necesarios deben estar disponibles en su entorno; en el caso de un destino de red, también es imprescindible que exista la conexión y que el extremo remoto sea accesible.

Prevé en el destino suficiente capacidad para las imágenes esperadas y su almacenamiento. El tamaño de un volcado depende, entre otras cosas, del contenido de la memoria y del filtrado. Un destino lleno o inaccesible puede impedir la copia de seguridad, incluso si la reserva se ha configurado correctamente.

Ni siquiera una instalación preparada garantiza que se obtenga un volcado útil. Un «oops» no provoca necesariamente un «panic»; en caso de pérdida total de alimentación, el kernel de captura deja de funcionar. Del mismo modo, un fallo grave de hardware puede impedir su arranque o la escritura de la imagen. Por lo tanto, la captura y el objetivo deben considerarse independientemente de la causa real del error.

Qué archivos se tienen en cuenta para el análisis

Para el análisis, no solo es importante el archivo de volcado. Si es posible, conserva también los archivos de kernel y los registros correspondientes, para poder comparar el estado en el momento del fallo con los mensajes y los cambios. La siguiente tabla distingue entre la imagen de memoria propiamente dicha y los archivos auxiliares que permiten su análisis.

Esto es especialmente importante vmlinux adecuado: La arquitectura y la compilación exacta del núcleo deben corresponder al núcleo del sistema que se ha bloqueado. El núcleo que se ejecute tras el reinicio puede ser otro. La salida de uname -r Por lo tanto, en el servidor recién reiniciado no basta con seleccionar el archivo correcto para el volcado antiguo.

Utiliza, además, una versión de crash compatible con el núcleo y el formato de volcado. Si hay controladores externos o adicionales que sean relevantes, ten a mano también sus archivos de módulo correspondientes y la información de depuración. Si faltan símbolos o se han filtrado páginas de memoria necesarias, el análisis puede verse limitado; dichas lagunas deben incluirse en la documentación del informe.

Un vmcore puede contener información confidencial de la memoria RAM. Por ello, limita el acceso, protege la transmisión y establece plazos de conservación y eliminación. Antes de enviar un volcado o registros complementarios a un servicio de asistencia técnica, aclara la autorización necesaria para ello y el alcance permitido.

Preparar «kdump» en el servidor

El punto de partida son la distribución, la versión y la arquitectura del servidor. Consulta en su documentación qué paquetes se necesitan para kdump y para cargar el núcleo de captura, y cómo se configura el servicio. Las instrucciones para las diferentes distribuciones no son intercambiables: los nombres de los paquetes, la configuración de arranque y las herramientas de comprobación pueden variar.

Parte de la preparación consiste en elegir la Reserva de memoria sobre el parámetro de arranque crashkernel. Selecciona el tamaño y, si procede, otros ajustes según las especificaciones de la plataforma y el hardware concretos. La memoria reservada no está disponible para el sistema que se ejecuta normalmente; por lo tanto, indicar un tamaño universal sería tan poco útil como copiar sin comprobar los valores de otro servidor.

Tras la configuración de arranque específica de la plataforma y, si fuera necesario, un reinicio, el siguiente comando de shell en modo lectura muestra los parámetros del núcleo que se está ejecutando actualmente. Busca en la salida crashkernel. Una entrada muestra la configuración pasada, pero no confirma ni que se haya cargado un kernel de captura ni que la copia de seguridad se haya realizado correctamente.

cat /proc/cmdline

En RHEL 9, además, puedes consultar el estado con el siguiente comando en la terminal. En otras distribuciones, debes seguir el procedimiento que se indica en la documentación correspondiente. Un resultado positivo Mensaje de estado Es un indicio importante de la disponibilidad, pero no sustituye a una prueba controlada de todo el proceso de seguridad.

kdumpctl status

Comprueba además si el destino previsto y los controladores necesarios para ello están disponibles en el sistema de captura. Anota la configuración seleccionada y la fecha de la comprobación, para poder volver a evaluarla tras cualquier cambio en el núcleo o en la infraestructura. Antes de la implementación, debes comprobar la configuración concreta para la plataforma de destino que se vaya a utilizar realmente.

Seleccionar el destino de la copia de seguridad y el alcance del volcado

El Objetivo de cobertura Debe estar accesible durante la captura y disponer de suficiente espacio libre. Un destino local evita la dependencia de una conexión de red, pero requiere espacio de almacenamiento útil en el servidor. Ten en cuenta también que varios volcados guardados y los archivos de diagnóstico asociados pueden ocupar espacio.

RHEL 9 documenta, además de los destinos locales, los destinos de red a través de NFS o SSH. Esto permite almacenar el archivo de forma independiente del servidor en cuestión; para ello, es necesario que la red, el equipo remoto y los componentes necesarios del sistema de captura funcionen correctamente. Comprueba las restricciones específicas de la configuración concreta de RHEL, en lugar de dar por sentado que la accesibilidad en condiciones normales de funcionamiento es la misma que en el sistema de captura.

Con makedumpfile La imagen se puede comprimir y filtrar según las áreas de memoria seleccionadas. Filtrado Puede ahorrar espacio de almacenamiento y volumen de transferencia, pero elimina páginas que podrían faltar para un análisis posterior. Por lo tanto, adapta el alcance del volcado al diagnóstico previsto y documenta los filtros utilizados; el archivo más pequeño no es necesariamente el más útil.

Un vmcore puede contener información confidencial de la memoria RAM. Por lo tanto, limita el acceso, protege la transmisión y establece durante cuánto tiempo se conservarán los archivos y cuándo se eliminarán. Antes de remitirlo a un servicio de asistencia, debes obtener la autorización necesaria; esto también se aplica a las copias almacenadas por separado.

Abrir un archivo vmcore existente con crash

Para el análisis posterior, necesitas el vmcore disponible, uno que se corresponda con la versión del kernel que se ha bloqueado y con la arquitectura vmlinux con información de depuración así como una versión de crash compatible con el núcleo y el formato de volcado. El núcleo que se ejecuta tras un reinicio puede ser otro; por lo tanto, la indicación de su versión por sí sola no identifica de forma fiable la compilación que ha sufrido un fallo.

El siguiente comando esquemático debe ejecutarse en el shell normal del sistema de análisis. Sustituye ambas rutas por las de los archivos reales. El comando abre una imagen existente para su análisis; no genera ningún volcado ni configura kdump.

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

Una vez superado el periodo de prueba, trabajarás en el mensaje de error, ya no en el shell normal. Allí se muestra log los mensajes del núcleo disponibles. Busca primero el mensaje de pánico y los mensajes que lo rodean; los mensajes pueden servir de punto de partida, pero no describen necesariamente la causa completa.

Con bt analizas la pila del contexto de análisis actual; bt -a Muestra las pilas de las tareas activas en las CPU. Compara las cadenas de llamadas con los mensajes, en lugar de considerar un único fotograma como prueba de la causa del error. Dependiendo del estado y el alcance del volcado, puede que falte información.

En la misma línea de comando, ayuda ps en la vista general de tareas; kmem -i Proporciona información general sobre la memoria. Esta instantánea por sí sola no demuestra ni la existencia de una fuga de memoria ni cuál es su causa. Si se desea examinar con más detalle un módulo implicado, puede ser necesario disponer además de los archivos del módulo correspondientes y de la información de depuración.

Clasificar las pilas y las notas de memoria

Si se produce un error de pánico tras un cambio en los controladores, anota en primer lugar el momento en que se produjo, la versión del kernel que falló y los módulos implicados. Compara estos datos con el registro de cambios: ¿solo se ha actualizado el controlador o se ha instalado al mismo tiempo un nuevo núcleo? De este modo, podrás delimitar qué cambios son relevantes para la investigación.

A continuación, lee con log los mensajes del núcleo disponibles y comprueba con bt la pila del contexto de análisis actual. bt -a complementa la visión de las tareas activas de las CPU. Anota, además del texto del «panic», los mensajes que lo precedieron; pueden proporcionar el contexto de un error que se detecte más adelante.

A Marco del controlador La presencia en la pila es un indicio, pero no una prueba de culpa. Por ejemplo, un daño anterior en la memoria puede no detectarse hasta que se ejecuta una función del controlador. Por lo tanto, comprueba si los mensajes, los módulos implicados y el flujo de ejecución coinciden antes de determinar que un cambio es la causa.

En caso de sospecha de almacenamiento, se facilita kmem -i Una visión general de la información sobre la memoria, en la medida en que el volcado y la herramienta la faciliten. Analiza estos valores junto con los mensajes del núcleo. Un valor aislado no prueba ni la existencia de una fuga de memoria ni su causa; además, es posible que falten páginas de memoria necesarias debido a la aplicación de filtros.

Para determinar si el consumo aumenta con el tiempo, necesitas series temporales complementarias. Si se analiza por separado la carga de la CPU, se puede Perfilado de la CPU con la herramienta Perf de Linux ayudar. Estas mediciones complementan el volcado de memoria, pero no sustituyen el estado registrado en él en el momento del fallo.

Si no hay ningún archivo vmcore válido

Tras un bloqueo y el posterior reinicio, lo primero que hay que aclarar es si realmente se ha producido un «Panic» y si se ha guardado un vmcore. El simple hecho de reiniciar no prueba ninguna de las dos cosas. Busca mensajes que coincidan con el momento del incidente y comprueba la ubicación de almacenamiento configurada antes de deducir que se trata de un error concreto por el hecho de que falte un archivo.

Analiza la Cadena de registro Por separado: ¿Se había cargado un kernel de captura en el sistema afectado y era el evento adecuado para activar kdump? No todos los «oops» provocan un «panic». Además, una pérdida total de alimentación o un fallo grave de hardware pueden impedir que el kernel de captura se inicie o escriba datos.

A continuación, comprueba el destino de la copia de seguridad: ¿era accesible, había espacio suficiente disponible y el sistema de captura incluía los controladores y componentes necesarios? En el caso de un destino de red, hay que tener en cuenta además la conexión y el equipo remoto como factores dependientes. En RHEL, el archivo kexec-dmesg.log Proporcionar información sobre la fase de registro, siempre que se haya creado y guardado.

A falta de un volcado útil, los registros anteriores o los mensajes persistentes de la consola y del núcleo son alternativas importantes. Sin embargo, estas fuentes no proporcionan una imagen completa de la memoria; el estado perdido no se puede reconstruir a posteriori con kdump.

Si los mensajes u otras observaciones indican que hay problemas en la red, se puede realizar una Análisis de la carga de las SoftIRQ de Linux ayuda a clasificar el procesamiento de paquetes. Responde a una cuestión distinta a la de la comprobación del destino del volcado y, por sí sola, no demuestra ni que se haya producido un «panic» ni que sea la causa de un fallo en la copia de seguridad.

Probar el registro y validar los resultados

Elige el alcance del volcado en función de la pregunta de diagnóstico prevista y de los recursos disponibles. La compresión y el filtrado pueden ahorrar espacio de almacenamiento y reducir el volumen de datos transmitidos; sin embargo, las páginas de memoria eliminadas ya no estarán disponibles para análisis posteriores. Documenta esta decisión para que, durante el análisis, quede claro qué datos podrían faltar.

Un vmcore puede contener información confidencial almacenada en memoria. Por lo tanto, regula el acceso, la transmisión segura y el plazo de conservación, así como el almacenamiento de los archivos de depuración correspondientes. Antes de remitirlo a un servicio de asistencia, aclara la autorización necesaria y el tratamiento previsto de los datos.

Vuelve a comprobar la preparación si se producen cambios en el núcleo, los controladores, la configuración de arranque o la infraestructura de copias de seguridad. Esto incluye el núcleo de captura cargado y la accesibilidad del destino seleccionado. Un mensaje de estado positivo es útil, pero por sí solo no indica si, en las condiciones actuales, se genera realmente un volcado que se pueda analizar.

Advertencia: Una prueba controlada de extremo a extremo provoca deliberadamente un fallo del sistema y puede dar lugar a reinicios y a la pérdida de datos. Realízala únicamente en un entorno de pruebas autorizado o durante una ventana de mantenimiento preparada para ello, con una copia de seguridad de los datos. Aclara de antemano las responsabilidades, las repercusiones y el proceso de reinicio; para ello, no se ha especificado deliberadamente ningún comando de activación.

Un significativo Prueba de extremo a extremo No te limites a comprobar el estado: comprueba si el archivo ha llegado al destino previsto y si se puede abrir con los archivos correspondientes a la compilación registrada. A continuación, durante la depuración del servidor, anota los hallazgos, los datos que faltan, las incertidumbres y los siguientes pasos de comprobación. Distingue claramente entre los indicios observados y las causas aún no confirmadas.