Arquivo PID presente, nenhum túnel: o OpenVPN chegou a rodar?

Quando o iniciador se recusa a iniciar o OpenVPN porque já existe um arquivo PID, a leitura natural é que há um túnel em execução em algum lugar. Essa leitura está errada com frequência suficiente para valer uma verificação antes de apagar qualquer coisa. Um arquivo num diretório de execução é contabilidade, e a contabilidade sobrevive a quedas, reinicializações e desligamentos interrompidos que não deixaram nenhum processo. Duas perguntas decidem o caso: existe um processo vivo e esse processo pertence a esta instância.

Comece pelo serviço, não pelo arquivo

A recusa normalmente vem de um iniciador e não do próprio OpenVPN. Ele lê um caminho, encontra algo ali e para antes de analisar uma configuração. A primeira pergunta é, portanto, sobre o contrato do iniciador, não sobre o túnel.

Leia a unidade ou o script que imprimiu a mensagem e anote três coisas: o caminho que ele verifica, o tipo de serviço que declara e se é responsável por escrever o arquivo. Uma unidade moderna pode usar supervisão simples ou notify e nunca tocar num arquivo PID, enquanto um script init antigo pode criar um sozinho. Copiar uma verificação de um modelo para o outro produz exatamente esse tipo de recusa. Descubra qual modelo está em uso antes de interpretar qualquer coisa.

Só então a pergunta passa a ser se uma instância está realmente em execução.

Verifique se esse identificador pertence à sua instância

Um número num arquivo prova que um número foi escrito. Ele não prova que exista agora um processo com esse identificador, e certamente não prova que o processo seja seu, porque os identificadores são reutilizados após uma reinicialização.

Compare a hora de início do processo com o carimbo de data do arquivo, o executável com o comando da unidade e a participação no serviço com o nome da unidade. Uma divergência em qualquer um dos três significa que você está olhando contabilidade e não um túnel.

Num host que executa contêineres ou vários namespaces, um identificador pode ser significativo numa visão e ausente noutra. Não ver um processo também não é prova de que ele não exista, se a sua conta não consegue inspecioná-lo. Verifique a partir do contexto que o iniciador usa antes de tirar conclusões.

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

O que o iniciador prometeu fazer com o arquivo

PIDFile= diz ao gerenciador de serviços de onde ler o identificador do processo principal. O gerenciador não escreve esse arquivo, mas remove o que sobrevive após o desligamento, e é exatamente por isso que uma saída interrompida pode deixar um arquivo.

Essa divisão de responsabilidades explica dois sintomas que as pessoas relatam como falhas. Um arquivo que nunca aparece significa que o daemon ou o seu script não conseguiram escrevê-lo, não que a supervisão esteja mal configurada. Um arquivo que sobrevive a uma parada significa que o caminho de desligamento nunca foi concluído.

Isso também explica por que as orientações atuais sugerem evitar a convenção quando a supervisão consegue acompanhar o processo principal diretamente. Essas orientações não são permissão para mudar o tipo de uma unidade empacotada, porque o comportamento do daemon em primeiro plano, em bifurcação ou em notificação tem de corresponder ao que a unidade declara. Mude o tipo sem mudar o daemon e você obtém uma unidade que relata falha enquanto o túnel roda, ou o contrário. Combine o par ou deixe ambos. A referência do serviço systemd descreve essa divisão de propriedade.

Desligamento limpo contra saída interrompida

Uma parada limpa pede ao daemon que saia, espera por ele e deixa o gerenciador arrumar a própria contabilidade. Uma saída interrompida, um processo morto ou uma reinicialização no meio do desligamento pulam partes dessa sequência, e o arquivo é o que resta. Encontrar um depois de uma queda diz que o desligamento não terminou, não que algo esteja escutando.

Compare o carimbo de data do arquivo com a última inicialização e com a última parada da unidade.

Depois verifique as provas vivas diretamente. Um socket ligado à porta VPN e uma interface de túnel com endereço são prova de que algo está rodando, de um modo que um arquivo de texto num diretório de execução nunca é. Se faltarem os dois, nada está rodando, diga o que disser o arquivo.

Pare de apagar o arquivo por hábito

Apagá-lo é um passo de recuperação legítimo depois de estabelecer que nenhuma instância o possui e que o iniciador documenta esse comportamento.

Como hábito permanente antes de iniciar, ele anula a verificação que você está contornando. Se arquivos obsoletos voltam depois de cada parada limpa, o escritor e o ciclo de vida do desligamento discordam sobre quem possui o caminho, e essa discordância é a falha que vale corrigir.

Mantenha um caminho independente para o host, inicie uma instância pelo gerenciador normal e leia o primeiro resultado. A próxima pessoa recebe uma unidade que ou funciona ou se explica.