Segfault do cliente VPN num Pi? Capture primeiro o processo

Inicia o cliente, o terminal imprime Segmentation fault (core dumped) e a hora seguinte vai para regravar o cartão. Essa mensagem descreve como um processo morreu num instante. Não diz que a placa está danificada, nem iliba a alimentação, o armazenamento ou a imagem.

Trabalhe a partir da linha que o shell imprimiu e volte ao processo por trás dela. Os factos úteis são qual executável falhou, em que ambiente e em que fase da ligação.

Comece pela linha que o shell imprimiu

O nome no seu comando é frequentemente um wrapper ou um lançador que inicia outro binário, por isso confirme qual executável o kernel realmente terminou. Anote o caminho completo, a versão do pacote e da aplicação, a arquitetura, a versão do sistema e do kernel, a conta que o iniciou e a hora exata. Um comando de shell com o nome de uma VPN inicia facilmente um processo auxiliar, e o registo nomeará esse auxiliar. Copiar a string de versão de um pacote instalado no mês passado não diz nada sobre o que correu.

Anote o que precedeu imediatamente a falha: arranque, análise do perfil, autenticação ou uma sessão que já passava tráfego. Essas quatro fases estreitam a busca muito mais do que a palavra segfault. Guarde a janela curta de registos em torno desse evento e deixe de fora as suposições sobre que alteração recente o causou até o registo o dizer.

Descubra se existe uma imagem de memória

A referência do ficheiro core descreve um dump como uma imagem da memória do processo escrita na terminação, e também lista as condições que impedem essa escrita. Essas condições incluem um limite de recursos igual a zero e um padrão core que encaminha o dump para outro local que não o diretório de trabalho. A ausência de um ficheiro chamado core não prova, portanto, nada sobre se houve uma falha. Verifique o padrão configurado e o limite antes de concluir que o sistema não produziu prova.

Num sistema que usa o coletor do systemd, a vista suportada correlaciona um registo guardado com um executável e uma hora. Uma entrada do journal e uma imagem de memória legível são dois artefactos diferentes: a política de retenção e as permissões podem deixá-lo com um e não com o outro. Pergunte à distribuição ou ao mantenedor da aplicação pelo fluxo de diagnóstico que suportam, porque um trace produzido noutra compilação ou noutro conjunto de bibliotecas costuma perder o tempo deles.

sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn

Repita essas leituras na máquina que realmente falhou. Fazê-las numa instalação nova responde a uma pergunta que ninguém fez.

Trate o dump como material que contém segredos

A memória do processo pode conter credenciais, chaves de sessão e conteúdo do perfil, o que torna um dump mais sensível do que o registo de texto ao lado. Redigir o registo não faz nada por uma imagem de memória opaca, e os gestores de issues comuns guardam anexos muito mais tempo do que dura uma conversa de suporte. Mova o ficheiro pelo canal privado que o fornecedor ou o mantenedor disponibiliza. Publicar um dump em bruto num issue público expõe tudo o que estava em memória quando o processo morreu, e não pode saber o que era até alguém o inspecionar.

Se um mantenedor pedir um trace, pergunte de que executável e de que bibliotecas o quer. Um backtrace cujos frames não correspondem à compilação reportada é difícil de confiar e fácil de ler mal.

Verifique a proveniência antes de substituir algo

Verifique a proveniência do pacote e a integridade dos ficheiros junto de quem possui a instalação, e preserve a configuração e o material de identidade antes de qualquer reparação controlada. Não sobreponha a única cópia da prova só para ver se uma instalação limpa arranca. Uma imagem nova que arranca diz que a nova imagem arranca. Não diz se a antiga continha um pacote corrompido, um cartão a falhar ou um binário que sempre falharia nesta arquitetura.

Se também falharem programas não relacionados, ou o sistema registar erros de armazenamento, alimentação ou kernel, guarde essas observações para a investigação da plataforma. Alargam o âmbito; não provam que todos os segfault vêm de RAM avariada ou de uma imagem corrompida.

Após uma correção dirigida, repita o mesmo arranque autorizado e a mesma operação VPN no mesmo hardware. Diga que falha parou e em que versão. Um arranque limpo por si só não identifica um componente defeituoso nem prevê a próxima falha de hardware.