Oops do núcleo ao iniciar a VPN: probas que paga a pena conservar

Iniciar o cliente de VPN é unha marca temporal cómoda, non unha causa, e esa distinción decide que ocorre despois. Cando un Oops do núcleo aparece preto dese momento, a elección está entre recoller un informe de fallo utilizábel e provocar o mesmo fallo cinco veces máis nunha máquina de produción. Garde catro cousas antes de reiniciar: a compilación exacta do núcleo, o primeiro rastro do fallo, o estado de taint e unha descrición breve de todo o demais que cambiou no mesmo minuto. O resto é interpretación, e a interpretación pode esperar ata que as probas estean nun lugar seguro.

Capture o primeiro fallo, non a última liña

O primeiro Oops do rexistro é o que importa, porque cada fallo posterior pode ser un dano colateral dun núcleo que xa non está san. Copie a cabeceira xunto co rastro de chamadas, xa que a cabeceira leva a instrución que fallou e o estado dos rexistros que identifican a ruta do código. Un informe que comeza na última liña vale moi pouco para quen o lea unha semana despois.

Se a máquina xa se reiniciou, o búfer do núcleo do arranque anterior adoita seguir no diario, sempre que naquel momento estivese activado o almacenamento persistente. Léao do ficheiro gardado en lugar de recrear a carga de traballo, porque unha segunda reprodución pode sobrescribir o que necesita. Onde a máquina non pode conservar un diario entre reinicios, unha consola serie ou netconsole é a única forma de que o fallo chegue a ser visíbel.

Fixe a compilación antes de ler calquera símbolo

Os nomes de funcións e os desprazamentos só teñen sentido respecto ao binario que os produciu, así que anote a cadea de versión do núcleo e o identificador de compilación da distribución á vez. Un ficheiro de símbolos doutra compilación apunta á liña equivocada con total confianza, o que é peor que non ter ningún símbolo. Conserve a versión do paquete do núcleo, non só o número upstream, porque as distribucións fan moitas retroportacións.

Os módulos fóra da árbore merecen a súa propia liña no rexistro, xa que un núcleo marcado limita o que un mantedor pode concluír. Lea o valor de taint en lugar de inferilo dunha lista de módulos.

Un taint distinto de cero non é unha acusación e non fai que o informe sexa inútil. Indica ao lector que compoñentes estaban cargados cando ocorreu o fallo, e algunhas bandeiras fan que un informe baixe de prioridade por política e non por criterio. Anote o valor, os nomes dos módulos e se o mesmo hardware e a mesma carga executaron algunha vez un núcleo sen eles. Esa última comparación é o que separa unha regresión nova dun erro de hai tempo.

Separe un disparador dun defecto

Iniciar o túnel normalmente exercita unha ruta que xa existía: un controlador de rede, unha disciplina de cola, unha función de offload ou un estado de enerxía. O disparador explica cando aparece o fallo, non que código está mal, e tratar o disparador como a causa leva a unha serie de cambios de configuración que non arranxan nada.

Unha imaxe anterior que funciona é unha proba, non unha demostración. Cambie un compoñente por arranque ao comparar, e garde os resultados nun lugar que sobreviva á máquina.

Comprobe que pode usar realmente o mantedor

Lea o informe como o faría un descoñecido antes de envialo. Se están a configuración, a secuencia exacta e a identidade de compilación, e as credenciais desapareceron, o informe é utilizábel. Se é unha captura dun rastro de pila, volverá cunha petición da mesma información. A guía de procura de erros do núcleo describe como son un rastro útil e uns 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 os comandos anteriores só len estado, e os dous primeiros deberían executarse antes do seguinte reinicio se a máquina aínda pode respondelos. Onde o diario non persiste, eses dous son os únicos que volverán funcionar algunha vez.

Redacte claves, contrasinais e tráfico non relacionado, pero conserve os nomes de funcións e os desprazamentos que alguén necesita para ler o rastro. Envíe o material pola vía de notificación que corresponda á distribución ou ao núcleo, non por un pegamento público cun nome de host adxunto. Despois espere unha pregunta en lugar de coller máis fallos, porque un fallo localizado contra unha compilación coincidente é o único resultado que fai avanzar o informe. Se non volve nada, a alternativa é unha reprodución controlada en hardware de reposto, nunca na máquina da que dependen outras persoas.