status=200/CHDIR: o systemd nunca iniciou o OpenVPN

O serviço falha, os logs mencionam um spawn e um diretório, e o primeiro instinto é verificar a configuração da VPN. Nesse ficheiro ainda não foi lido nada. O systemd falhou ao preparar o processo, antes de o executável arrancar, pelo que não foi consultado nenhum parser, nenhum certificado e nenhum host remoto. Ler o código de estado como uma afirmação sobre o systemd em vez de sobre o OpenVPN é o que transforma isto numa investigação curta.

Leia o código de estado antes da aplicação

O código numérico depois do nome do serviço nomeia a etapa que falhou. Uma falha de diretório é reportada como estado CHDIR, enquanto um executável que não pôde ser executado é um código completamente diferente. Os dois parecem iguais numa linha de resumo e não têm nada em comum nas suas causas.

Essa distinção importa porque as correções estão em ficheiros diferentes. Uma falha CHDIR diz respeito a um caminho e à forma como o serviço o vê. Uma falha exec diz respeito ao binário, ao seu interpretador ou a uma montagem não relacionada. Alterar o remote da VPN, a lista de cifras ou o caminho do certificado não resolve nenhuma das duas.

Confirme que a falha ocorre no arranque e não depois de uma execução bem-sucedida. Se o serviço funcionava ontem e agora falha na mesma etapa, algo mudou no diretório, nas suas permissões ou na própria unit, e essa mudança é a evidência a procurar.

Pergunte à unit onde quer estar

Leia a unit efetiva em vez do ficheiro que pensa estar instalado, porque os drop-ins podem substituir o diretório de trabalho sem que alguma vez tenha editado a unit principal. A saída de show responde diretamente à pergunta:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

Para o modelo do servidor upstream, o diretório de trabalho é o diretório de configuração do servidor e o nome da instância seleciona o perfil lá dentro. Uma instância chamada branch espera, por isso, o seu próprio ficheiro nesse mesmo diretório, e um perfil colocado noutro sítio não satisfaz de todo o requisito do diretório de trabalho.

Compare o que a unit pede com o que existe. Um caminho que existia, um link simbólico que agora aponta para outro sítio ou um nome de instância que já não corresponde a um diretório são alterações correntes que produzem exatamente esta falha.

Verifique o caminho tal como o serviço o vê

A sua shell e o serviço não partilham a mesma vista do sistema de ficheiros. Um diretório raiz ou uma imagem raiz configurados mudam o que significa um caminho absoluto dentro da unit, e um caminho que está obviamente presente no host pode faltar nesse espaço de nomes. Leia as definições da unit antes de confiar num teste manual.

As permissões agravam o problema. O serviço corre como um utilizador específico, e esse utilizador tem de poder atravessar cada diretório pai para chegar ao alvo, não apenas ler o próprio alvo. Um diretório legível pelo root e não atravessável pelo utilizador do serviço produz uma falha que parece um caminho inexistente.

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

As definições de endurecimento também fazem parte deste quadro. Uma unit que esconde os diretórios pessoais ou torna uma parte do sistema de ficheiros só de leitura faz exatamente aquilo para que foi configurada, e o diretório de trabalho tem de viver num local que o sandbox ainda exponha.

Corrija o proprietário e depois espere outro erro

Corrija a disposição ou a unit através de quem possui essa configuração. Mover um perfil para o diretório esperado é uma correção legítima quando a disposição está errada, mas não explica um diretório em que não se consegue entrar, por isso não a trate como a resposta geral.

Resista ao atalho de alargar as permissões na árvore de configuração ou de remover o sandbox. Ambos fazem o sintoma desaparecer ao mesmo tempo que removem as proteções que ali foram colocadas deliberadamente, e a próxima falha será mais difícil de interpretar.

Reinicie a instância e leia o evento seguinte em vez de assumir o sucesso. O próximo erro provável é o OpenVPN não conseguir abrir o seu ficheiro de configuração, o que é um progresso: entrou-se no diretório de trabalho e o parser está agora a correr. Siga a partir daí o mapeamento real de ficheiros da unit em vez de voltar à resolução de problemas de rede.

A referência de execução do systemd define como o diretório de trabalho é interpretado juntamente com os diretórios raiz e o isolamento. O padrão a reter é simples: cada código de estado nomeia uma etapa diferente, e só os erros da própria aplicação descrevem a aplicação.