OpenVPN arrancou mas não imprimiu nada: verifique primeiro o log-append

Inicia o OpenVPN a partir de uma shell com um ficheiro de configuração, e o terminal fica ali sem qualquer saída. Sem banner, sem erro, sem prompt. O instinto diz que o arranque falhou, por isso inicia outra cópia, depois outra, e a máquina acaba com várias instâncias meio configuradas. Antes de tudo isso, verifique no perfil se existe uma diretiva que já redirecionou o registo para outro sítio. O silêncio é uma propriedade da consola, não do processo.

O silêncio tem duas explicações muito diferentes

A primeira é que o processo está a correr bem e a escrever num ficheiro que não está a observar. A segunda é que terminou imediatamente com um erro registado nesse mesmo ficheiro.

Ambos deixam um terminal vazio, e uma pergunta separa-os: existe um processo agora, e o que está no ficheiro para onde lhe foi dito que escrevesse. Responda a isso antes de tocar novamente na configuração. Reiniciar para obter saída é como duas instâncias acabam a lutar por um único dispositivo de túnel e pela mesma porta, o que produz erros sem qualquer relação com o problema original.

Encontre a diretiva e, depois, encontre o processo.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Encontre o destino que o processo em execução utiliza

Leia o perfil com que o processo foi realmente iniciado, não o que editou. Uma instância gerida por um serviço carrega normalmente um caminho diferente e corre num diretório de trabalho diferente, pelo que um nome de ficheiro relativo é resolvido num sítio que não esperava.

Uma diretiva cd explícita torna essa distinção mais nítida, porque o caminho relativo se desloca com a mudança de diretório. Se herdou esta configuração, o ficheiro pode estar num sítio onde agora ninguém iria procurar.

Compare a hora de modificação do ficheiro com o momento em que arrancou. Um registo da semana passada é prova sobre a semana passada. Depois leia as últimas linhas do ficheiro que mudou, e trate o que ali está como a mensagem de arranque que lhe faltava.

log versus log-append: prova e apagamento

log-append acrescenta ao que já está no ficheiro. log abre o ficheiro para escrita e trunca-o, pelo que alternar entre os dois pode apagar a execução que ia ler.

Se alguém alterou a diretiva durante a depuração, a prova anterior já desapareceu e o tamanho do ficheiro parecerá suspeitosamente pequeno. Vale a pena saber isso antes de comparar duas execuções e concluir que algo mudou. Apague um registo de propósito, ou guarde-o, mas saiba qual dos dois fez. A prova que removeu deliberadamente é mais fácil de raciocinar do que a que perdeu por acidente.

Nenhuma das opções cria diretórios principais em falta, e nenhuma concede acesso através das permissões do sistema de ficheiros ou de uma sandbox de serviço. Um caminho que parece correto na configuração pode ainda assim não ser escrevível pela conta com que o daemon corre, e nesse caso o daemon pode falhar antes de conseguir reportar alguma coisa. Verifique a existência do diretório e o seu proprietário antes de assumir que o nome do ficheiro é o problema.

Quando um wrapper de serviço captura a saída

No systemd, a saída padrão e os erros vão para o journal, a menos que uma diretiva de ficheiro explícita tenha precedência, e um wrapper do fornecedor pode capturá-los noutro sítio completamente diferente.

É por isso que o mesmo perfil se comporta de forma diferente a partir de uma shell e de uma unit. O ambiente da unit, o seu diretório de trabalho e os seus fluxos padrão diferem todos da sua shell interativa. Um caminho relativo pode resolver-se num contexto e não chegar a lado nenhum no outro. Leia a definição da unit quando os dois discordam, não o perfil.

Compare os dois arranjos de arranque em vez de concluir que um deles está avariado. Leia a linha de comando da unit e o seu ambiente, e depois leia o journal para a mesma janela temporal. Se o wrapper redireciona a saída para o seu próprio ficheiro, esse ficheiro é agora o seu registo, e as diretivas do OpenVPN são irrelevantes para onde as mensagens foram.

Aumente a verbosidade só depois de a conseguir ler

Aumentar a verbosidade antes de encontrar o destino só produz mais texto num local que não está a observar.

Assim que souber onde a saída aterra, um nível moderado mostra o perfil a ser analisado e a ligação a ser tentada. Dois ou três chegam para um problema de arranque. Níveis mais altos justificam-se quando a falha é um detalhe de negociação, e também fazem o ficheiro crescer depressa.

Depois leia o erro real. Um terminal silencioso não prova nada sobre se o túnel subiu, e a falha registada no ficheiro é a que vale a pena corrigir.