¿Dónde están los registros de kernel panic?

Tengo un problema con Handbrake / ffmpeg. Después de ~ 5 minutos de transcodificación, la computadora se bloquea. Estoy bastante seguro de que es un pánico del núcleo porque el bloqueo de mayúsculas comienza a parpadear.

Hay algunas preguntas lógicas sobre qué hacer y algunas sobre errores específicos, pero realmente estoy detrás de una cosa: ¿qué sucedió justo antes de que todo muriera?

Lo he comprobado /var/log/kern.logy todo lo que veo alrededor del tiempo es que me quedo en un DVD y luego, unos minutos después, el sistema se inicia. Sin errores, sin aviso de pánico.

¿Hay alguna forma de forzar el registro de pánico? Estoy bastante seguro de que puedo reproducir esto (sucedió el 100% de las veces que lo intenté recientemente), así que aunque prefiero que esto "simplemente funcione", estoy feliz de reiniciar algunas veces si eso significa que puedo Encuentra la causa del pánico.

Todos los registros de su sistema en Ubuntu son manejados por lo rsyslogque mantiene su configuración en /etc/rsyslog.confy /etc/rsyslog.d/.

Para obtener más información sobre cómo configurar rsyslogy las posibles opciones, visite el rsyslog.conf man page.

Al abrir /etc/rsyslog.d/50-default.conf, puede ver que una de las líneas contiene

*.*;auth,authpriv.none -/var/log/syslog*

Lo que significa que el archivo que está buscando en este caso es cualquiera de los enormes /var/log/syslogregistros que probablemente tenga.

Puede ver que el nombre del archivo también comienza con un -, esto significa que el archivo se almacena en caché antes de escribir, es genial, pero puede dejarlo con un registro incorrecto, lo que desea es que el registro se escriba tan pronto como haya un problema. Retire el tablero y reinicie o vuelva a cargar rsyslogy luego haga que su computadora se bloquee nuevamente, verifique /var/log/syslog.

Si realmente es un kernel panic, entonces no se escribirá en un registro a través de métodos normales. Dado que el núcleo se ha bloqueado en este momento, escribir en el sistema de archivos es una operación arriesgada: ya no se puede confiar en gran parte del núcleo, por lo que las escrituras en los registros podrían estar arrojando basura al azar sobre su cargador de arranque.

En cambio, puede volcar el contenido de la memoria en su intercambio y luego depurarlo más tarde. Esto se conoce como caída del núcleo / volcado del núcleo.

Ubuntu Wiki tiene una CrashdumpRecipe que puede ser útil, aunque parece un poco desactualizada, no creo que demasiado debería haber cambiado.

Puerto serial

El puerto serie es un simple mecanismo de comunicación de bajo nivel entre computadoras.

Ventajas:

• configuración simple una vez (si tiene el hardware)
• confiable, ya que la transmisión de datos solo depende de una API de kernel y cables simple, que es menos probable que se vea afectada por el pánico que, por ejemplo, el subsistema TCP / IP.

Desventajas:

• La mayoría de las computadoras portátiles modernas ya no tienen el puerto serie (¿expuesto?) para ahorrar espacio. Pero las computadoras de escritorio y las máquinas virtuales aún lo hacen.
• También necesita una segunda computadora con puerto serie para recibir los datos, pero este es el caso de básicamente todas las placas de desarrollo integradas como la Raspberry Pi.
• limitado por la longitud del cable serie de la capa física, a diferencia de las redes TCP / IP que son ilimitadas. Sin embargo, esto puede solucionarse con un dispositivo que interactúe entre serie y TCP / IP. Pero hay dispositivos que convierten entre los dos.

El puerto serie se ve así:

y en el RPI está disponible a través de GPIO.

Luego, si tiene el hardware requerido, conéctese desde la segunda computadora a la computadora principal con:

screen /dev/ttyS0 115200

Esto realmente te da una concha.

Luego, en la máquina principal, inicie la operación que entra en pánico.

Cuando ocurre el pánico, el volcado de pánico se transmite a la segunda máquina, y puede verlo todo desplazándose hacia arriba en el terminal.

Otros metodos

También hay otros métodos que superan las limitaciones de hardware mencionadas anteriormente, a costa de ser más complejas y menos confiables. Métodos notables:

• netdump: transmite el pánico a través de TCP / IP. Se basa en que el subsistema TCP / IP no esté dañado.
• kdump: parece ser el mecanismo subyacente de linux-crashdump mencionado en: https://askubuntu.com/a/104793/52975 Inicia un segundo kernel de Linux para examinar el kernel bloqueado . ¡¿Qué podría salir mal?! :-)

Vea también esta gran respuesta: https://unix.stackexchange.com/questions/60574/determining-cause-of-linux-kernel-panic

Paso de depuración

En última instancia, obtener resultados de pánico requiere que algunas funciones del núcleo funcionen, y cualquier funcionalidad del núcleo podría corromperse por el pánico.

Pero, ¿quién necesita el pánico si puede usar GDB en el núcleo? Si eres así de duro, mira:

• QEMU u otras máquinas virtuales: https://stackoverflow.com/a/42316607/895245
• JTAG

Cada problema cae una vez que tiene visibilidad completa (¡y suficiente tiempo!).