Oops del núcleo al iniciar la VPN: pruebas que vale la pena conservar

Iniciar el cliente de VPN es una marca temporal cómoda, no una causa, y esa distinción decide qué ocurre después. Cuando un Oops del núcleo aparece cerca de ese momento, la elección está entre recoger un informe de fallo utilizable y provocar el mismo fallo cinco veces más en una máquina de producción. Guarde cuatro cosas antes de reiniciar: la compilación exacta del núcleo, el primer rastro del fallo, el estado de taint y una descripción breve de todo lo demás que cambió en el mismo minuto. El resto es interpretación, y la interpretación puede esperar hasta que las pruebas estén en un lugar seguro.

Capture el primer fallo, no la última línea

El primer Oops del registro es el que importa, porque cada fallo posterior puede ser un daño colateral de un núcleo que ya no está sano. Copie la cabecera junto con el rastro de llamadas, ya que la cabecera lleva la instrucción que falló y el estado de los registros que identifican la ruta del código. Un informe que empieza en la última línea vale muy poco para quien lo lea una semana después.

Si la máquina ya se ha reiniciado, el búfer del núcleo del arranque anterior suele seguir en el diario, siempre que en ese momento estuviera activado el almacenamiento persistente. Léalo del archivo guardado en lugar de recrear la carga de trabajo, porque una segunda reproducción puede sobrescribir lo que necesita. Donde la máquina no puede conservar un diario entre reinicios, una consola serie o netconsole es la única forma de que el fallo llegue a ser visible.

Fije la compilación antes de leer cualquier símbolo

Los nombres de funciones y los desplazamientos solo tienen sentido respecto al binario que los produjo, así que anote la cadena de versión del núcleo y el identificador de compilación de la distribución a la vez. Un archivo de símbolos de otra compilación apunta a la línea equivocada con total confianza, lo que es peor que no tener ningún símbolo. Conserve la versión del paquete del núcleo, no solo el número upstream, porque las distribuciones hacen muchas retroportaciones.

Los módulos fuera del árbol merecen su propia línea en el registro, ya que un núcleo marcado limita lo que un mantenedor puede concluir. Lea el valor de taint en lugar de inferirlo de una lista de módulos.

Un taint distinto de cero no es una acusación y no hace que el informe sea inútil. Indica al lector qué componentes estaban cargados cuando ocurrió el fallo, y algunas banderas hacen que un informe baje de prioridad por política y no por criterio. Anote el valor, los nombres de los módulos y si el mismo hardware y la misma carga ejecutaron alguna vez un núcleo sin ellos. Esa última comparación es lo que separa una regresión nueva de un error de hace tiempo.

Separe un disparador de un defecto

Iniciar el túnel normalmente ejercita una ruta que ya existía: un controlador de red, una disciplina de cola, una función de offload o un estado de energía. El disparador explica cuándo aparece el fallo, no qué código está mal, y tratar el disparador como la causa lleva a una serie de cambios de configuración que no arreglan nada.

Una imagen anterior que funciona es una prueba, no una demostración. Cambie un componente por arranque al comparar, y guarde los resultados en un lugar que sobreviva a la máquina.

Compruebe qué puede usar realmente el mantenedor

Lea el informe como lo haría un desconocido antes de enviarlo. Si están la configuración, la secuencia exacta y la identidad de la compilación, y las credenciales han desaparecido, el informe es utilizable. Si es una captura de un rastro de pila, volverá con una petición de la misma información. La guía de búsqueda de errores del núcleo describe cómo son un rastro útil y unos símbolos coincidentes.

uname -r
cat /proc/sys/kernel/tainted
journalctl -k -b -1 --no-pager | sed -n '/BUG:/,/Call Trace/p'
dmesg -T | grep -A 40 'RIP:'

Todos los comandos anteriores solo leen estado, y los dos primeros deberían ejecutarse antes del siguiente reinicio si la máquina aún puede responderlos. Donde el diario no persiste, esos dos son los únicos que volverán a funcionar alguna vez.

Redacte claves, contraseñas y tráfico no relacionado, pero conserve los nombres de funciones y los desplazamientos que alguien necesita para leer el rastro. Envíe el material por la vía de notificación que corresponda a la distribución o al núcleo, no por un pegado público con un nombre de host adjunto. Luego espere una pregunta en lugar de cosechar más fallos, porque un fallo localizado contra una compilación coincidente es el único resultado que hace avanzar el informe. Si no vuelve nada, la alternativa es una reproducción controlada en hardware de repuesto, nunca en la máquina de la que dependen otras personas.