A unidade -.mount está enmascarada: o cliente OpenVPN non arrinca
Un ficheiro -.mount perdido en /run/systemd/system enmascara a unidade de montaxe raíz, así que toda unidade que necesita o sistema de ficheiros falla antes de que OpenVPN arrinque.
O seu servizo falla antes de que OpenVPN chegue a executarse, e o erro fala dunha unidade de montaxe que nunca configurou. Ese é o sinal: systemd rexeita toda a transacción porque a unidade de montaxe raíz está enmascarada, e o seu perfil de VPN aínda non se leu. A causa habitual é un ficheiro sobrante no directorio de unidades en tempo de execución, non unha fstab rota nin un certificado que falte. Siga primeiro o ficheiro, porque é a explicación máis barata de descartar.
O erro nomea a montaxe raíz, non o seu perfil
systemd xera a unidade de montaxe raíz a partir da información de montaxe do núcleo, e nomea a unidade -.mount porque un guión representa a ruta raíz. Esa unidade normalmente só existe en memoria e non ten ningún ficheiro detrás. Cando o erro di que está enmascarada, alguén puxo un ficheiro de unidade onde systemd o cargará e apuntou ese ficheiro a /dev/null. A máscara é un estado real, non unha errata da mensaxe.
A unidade de instancia falla porque o seu grafo de traballos chega á montaxe raíz mediante a ordenación e mediante os seus propios requisitos de montaxe. A transacción rexéitase antes de que se execute o binario de OpenVPN, así que nada da configuración do cliente pode ser a causa. Por iso cambiar perfís, certificados ou credenciais non ten ningún efecto neste fallo concreto.
Revise o directorio de execución antes de depurar OpenVPN
Busque un ficheiro con ese nome exacto no directorio de unidades en tempo de execución e despois pregunte a systemd que cre que é a unidade. As dúas respostas son rápidas e, xuntas, separan un ficheiro sobrante dun problema de montaxe real.
ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount
Unha máquina normal non ten ese ficheiro, e a lista de enmascarados non contén a montaxe raíz. Se o primeiro comando imprime unha ligazón simbólica a /dev/null, o diagnóstico está resolto. O mesmo directorio pode conter unha máscara de tmp.mount creada polas mesmas ferramentas, e iso produce a mesma clase de fallo con outro nome. Mire o directorio enteiro e non só o nome do erro.
ls -la /run/systemd/system/*.mount
Se o directorio está limpo e a unidade segue enmascarada, a máscara vive noutro lugar da ruta de busca, e systemctl cat -.mount mostrará que ficheiro se carga.
Borren o ficheiro, recarguen e volvan arrincar
Basta con quitar o ficheiro de execución e recargar o xestor, e non toca nada que veña dun paquete. Recargue antes de arrincar, porque systemd conserva o estado da unidade cargada ata que volve ler o directorio.
sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]
Despois lea o rexistro do propio servizo en lugar de supoñer que a corrección funcionou. Un arrinque limpo só demostra que systemd aceptou a unidade; o cliente aínda pode morrer por un perfil ausente, un par inalcanzable ou un certificado que non valida. Son problemas normais de OpenVPN que quedaban ocultos detrás da unidade enmascarada. O rexistro anota que perfil se cargou e se o túnel chegou a establecerse. Se a unidade arrinca e o túnel non, pasou a outro problema, o que é un avance.
journalctl -u [email protected] -b --no-pager
Como /run é un sistema de ficheiros temporal, un reinicio tamén borra o ficheiro. Iso converte o reinicio nunha proba útil: se o servizo funciona tras un reinicio e volve fallar tras o seguinte despregamento, o ficheiro estase a cocer na imaxe.
Evite que volva desde a imaxe
Un modelo de contedor ou de máquina virtual que enmascara unidades de montaxe durante a súa construción levará esa máscara a cada clon. O seguinte que necesite o sistema de ficheiros rompe, e a mensaxe culpa a montaxe en lugar da imaxe da que veu. Arranxalo dentro dunha instancia en execución agocha o problema ata que se crea a instancia seguinte.
Busque no contexto de construción o nome do ficheiro e o comando que o crea, despois quite a máscara do modelo e volva construír. Se a máscara é realmente necesaria durante a construción, quítea na mesma capa que remata a construción, para que a imaxe enviada arrinque limpa. Verifique nun clon novo e non na máquina que reparou a man. É a única proba que demostra que a imaxe cambiou.
O síntoma que cómpre lembrar é o desaxuste entre o erro e o que estaba configurando. Cando systemd se queixa dunha montaxe mentres arrinca un cliente VPN, lea o nome da unidade na mensaxe antes de ler o nome do servizo.