Oops do kernel ao iniciar a VPN: evidências que vale a pena guardar

Iniciar o cliente VPN é um carimbo de tempo conveniente, não uma causa, e essa distinção decide o que acontece a seguir. Quando um Oops do kernel ocorre perto desse momento, a escolha é entre recolher um relatório de falha utilizável e provocar o mesmo crash mais cinco vezes numa máquina de produção. Guarde quatro coisas antes de reiniciar: a compilação exata do kernel, o primeiro rastro da falha, o estado de taint e uma descrição breve de tudo o resto que mudou no mesmo minuto. O resto é interpretação, e a interpretação pode esperar até que as evidências estejam num lugar seguro.

Capture a primeira falha, não a última linha

O primeiro Oops no registo é o que importa, porque cada falha posterior pode ser dano colateral de um kernel já doente. Copie o cabeçalho junto com o rastro de chamadas, pois o cabeçalho contém a instrução que falhou e o estado dos registos que identificam o caminho do código. Um relatório que começa na última linha vale muito pouco para quem o ler uma semana depois.

Se a máquina já reiniciou, o buffer do kernel do arranque anterior muitas vezes ainda está no diário, desde que o armazenamento persistente estivesse ativo na altura. Leia-o do ficheiro guardado em vez de recriar a carga de trabalho, porque uma segunda reprodução pode sobrescrever o que precisa. Onde a máquina não consegue manter um diário entre reinícios, uma consola série ou netconsole é a única forma de a falha alguma vez ser visível.

Fixe a compilação antes de ler qualquer símbolo

Nomes de funções e deslocamentos só fazem sentido em relação ao binário que os produziu, por isso registe a string de versão do kernel e o identificador de compilação da distribuição em conjunto. Um ficheiro de símbolos de outra compilação aponta para a linha errada com total confiança, o que é pior do que não ter símbolo nenhum. Guarde a versão do pacote do kernel, não apenas o número upstream, porque as distribuições fazem muitos backports.

Os módulos fora da árvore merecem a sua própria linha no registo, pois um kernel marcado limita o que um mantenedor pode concluir. Leia o valor de taint em vez de o inferir de uma lista de módulos.

Um taint diferente de zero não é uma acusação e não torna o relatório inútil. Diz ao leitor que componentes estavam carregados quando a falha ocorreu, e algumas flags fazem com que um relatório seja despriorizado por política e não por julgamento. Registe o valor, os nomes dos módulos e se o mesmo hardware e a mesma carga alguma vez executaram um kernel sem eles. É essa última comparação que separa uma regressão nova de um erro antigo.

Separe um gatilho de um defeito

Iniciar o túnel normalmente exercita um caminho que já existia: um controlador de rede, uma disciplina de fila, uma função de offload ou um estado de energia. O gatilho explica quando a falha aparece, não que código está errado, e tratar o gatilho como a causa leva a uma série de alterações de configuração que não corrigem nada.

Uma imagem anterior que funciona é prova, não demonstração. Ao comparar, mude um componente por arranque e guarde os resultados num lugar que sobreviva à máquina.

Verifique o que o mantenedor pode realmente usar

Leia o relatório como um estranho o leria antes de o enviar. Se a configuração, a sequência exata e a identidade da compilação estiverem presentes, e as credenciais tiverem sido removidas, o relatório é utilizável. Se for uma captura de um rastro de pilha, voltará com um pedido das mesmas informações. O guia de caça a erros do kernel descreve como são um rastro útil e símbolos correspondentes.

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:'

Cada comando acima apenas lê estado, e os dois primeiros devem ser executados antes do próximo reinício se a máquina ainda conseguir responder-lhes. Onde o diário não é persistente, esses dois são os únicos que voltarão a funcionar alguma vez.

Remova chaves, palavras-passe e tráfego não relacionado, mas mantenha os nomes de funções e os deslocamentos de que alguém precisa para ler o rastro. Envie o material pelo caminho de notificação aplicável à distribuição ou ao kernel, não por uma colagem pública com um nome de host anexado. Depois espere por uma pergunta em vez de colher mais crashes, porque uma falha localizada contra uma compilação correspondente é o único resultado que faz o relatório avançar. Se nada voltar, a alternativa é uma reprodução controlada em hardware de reserva, nunca na máquina de que outras pessoas dependem.