A unidade -.mount está mascarada: o cliente OpenVPN não inicia

O seu serviço falha antes de OpenVPN chegar a executar-se, e o erro fala de uma unidade de montagem que nunca configurou. É esse o sinal: o systemd recusa toda a transação porque a unidade de montagem raiz está mascarada, e o seu perfil de VPN ainda não foi lido. A causa habitual é um ficheiro deixado no diretório de unidades de execução, não uma fstab avariada e não um certificado em falta. Siga primeiro o ficheiro, porque é a explicação mais barata de descartar.

O erro nomeia a montagem raiz, não o seu perfil

O systemd gera a unidade de montagem raiz a partir da informação de montagem do kernel, e nomeia a unidade -.mount porque um hífen representa o caminho raiz. Essa unidade normalmente só existe em memória e não tem qualquer ficheiro por trás. Quando o erro diz que está mascarada, alguém colocou um ficheiro de unidade onde o systemd o vai carregar e apontou esse ficheiro para /dev/null. A máscara é um estado real, não um erro de escrita na mensagem.

A unidade de instância falha porque o seu grafo de tarefas chega à montagem raiz através da ordenação e dos seus próprios requisitos de montagem. A transação é recusada antes de o binário do OpenVPN ser executado, por isso nada na configuração do cliente pode ser a causa. É por isso que mudar perfis, certificados ou credenciais não tem qualquer efeito nesta falha concreta.

Verifique o diretório de execução antes de depurar o OpenVPN

Procure um ficheiro com esse nome exato no diretório de unidades de execução e depois pergunte ao systemd o que pensa que a unidade é. Ambas as respostas são rápidas e, em conjunto, separam um ficheiro deixado de um problema real de montagem.

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

Uma máquina normal não tem esse ficheiro, e a lista de mascarados não contém a montagem raiz. Se o primeiro comando imprimir um link simbólico para /dev/null, o diagnóstico está fechado. O mesmo diretório pode conter uma máscara tmp.mount criada pelas mesmas ferramentas, e isso produz a mesma classe de falha com outro nome. Olhe para o diretório inteiro e não apenas para o nome do erro.

ls -la /run/systemd/system/*.mount

Se o diretório estiver limpo e a unidade continuar mascarada, a máscara está noutro ponto do caminho de pesquisa, e systemctl cat -.mount mostrará que ficheiro está a ser carregado.

Apague o ficheiro, recarregue e arranque de novo

Basta remover o ficheiro de execução e recarregar o gestor, e isso não toca em nada que venha de um pacote. Recarregue antes de arrancar, porque o systemd mantém o estado da unidade carregada até reler o diretório.

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

Depois leia o registo do próprio serviço em vez de assumir que a correção funcionou. Um arranque limpo prova apenas que o systemd aceitou a unidade; o cliente ainda pode morrer por um perfil ausente, um par inalcançável ou um certificado que não valida. São problemas normais do OpenVPN que estavam escondidos atrás da unidade mascarada. O registo anota que perfil foi carregado e se o túnel chegou a ser estabelecido. Se a unidade arranca e o túnel não, passou para outro problema, o que é um avanço.

journalctl -u [email protected] -b --no-pager

Como /run é um sistema de ficheiros temporário, um reinício também apaga o ficheiro. Isso faz do reinício um teste útil: se o serviço funciona após um reinício e volta a falhar após a implantação seguinte, o ficheiro está a ser incluído na imagem.

Impeça que volte da imagem

Um modelo de contentor ou de máquina virtual que mascara unidades de montagem durante a sua construção levará essa máscara para cada clone. O que precisar do sistema de ficheiros a seguir avaria, e a mensagem culpa a montagem em vez da imagem de onde veio. Corrigir dentro de uma instância em execução esconde o problema até a instância seguinte ser criada.

Procure no contexto de construção o nome do ficheiro e o comando que o cria, depois retire a máscara do modelo e construa de novo. Se a máscara for realmente necessária durante a construção, retire-a na mesma camada que termina a construção, para que a imagem enviada arranque limpa. Verifique num clone novo e não na máquina que reparou à mão. É o único teste que prova que a imagem mudou.

O sintoma a recordar é o desfasamento entre o erro e aquilo que estava a configurar. Quando o systemd se queixa de uma montagem enquanto arranca um cliente VPN, leia o nome da unidade na mensagem antes de ler o nome do serviço.