L’unité -.mount est masquée : le client OpenVPN ne démarre pas

Votre service échoue avant même que OpenVPN ne s’exécute, et l’erreur parle d’une unité de montage que vous n’avez jamais configurée. C’est l’indice : systemd refuse toute la transaction parce que l’unité de montage racine est masquée, et votre profil VPN n’a pas encore été lu. La cause habituelle est un fichier oublié dans le répertoire des unités d’exécution, pas une fstab cassée ni un certificat manquant. Suivez d’abord le fichier, car c’est l’explication la moins coûteuse à écarter.

L’erreur nomme le montage racine, pas votre profil

systemd génère lui-même l’unité de montage racine à partir des informations de montage du noyau, et il nomme l’unité -.mount parce qu’un tiret représente le chemin racine. Cette unité n’existe normalement qu’en mémoire et n’a aucun fichier derrière elle. Quand l’erreur dit qu’elle est masquée, quelque chose a déposé un fichier d’unité là où systemd le chargera et a pointé ce fichier vers /dev/null. Le masquage est un état réel, pas une faute de frappe dans le message.

L’unité d’instance échoue parce que son graphe de tâches atteint le montage racine par l’ordonnancement et par ses propres exigences de montage. La transaction est refusée avant l’exécution du binaire OpenVPN, donc rien dans la configuration du client ne peut être la cause. C’est pourquoi changer de profil, de certificat ou d’identifiants n’a aucun effet sur cette panne précise.

Inspectez le répertoire d’exécution avant de déboguer OpenVPN

Cherchez un fichier portant exactement ce nom dans le répertoire des unités d’exécution, puis demandez à systemd ce qu’il pense de l’unité. Les deux réponses sont rapides et, ensemble, elles distinguent un fichier oublié d’un vrai problème de montage.

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

Une machine normale n’a pas ce fichier, et la liste des unités masquées ne contient pas le montage racine. Si la première commande affiche un lien symbolique vers /dev/null, le diagnostic est établi. Le même répertoire peut contenir un masque tmp.mount créé par les mêmes outils, et cela produit la même classe de panne sous un autre nom. Regardez tout le répertoire et pas seulement le nom cité dans l’erreur.

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

Si le répertoire est propre et que l’unité reste masquée, le masque se trouve ailleurs dans le chemin de recherche, et systemctl cat -.mount indiquera quel fichier est chargé.

Supprimez le fichier, rechargez et redémarrez

Supprimer le fichier d’exécution et recharger le gestionnaire suffit, et cela ne touche à rien qui vienne d’un paquet. Rechargez avant de démarrer, car systemd conserve l’état de l’unité chargée jusqu’à ce qu’il relise le répertoire.

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

Lisez ensuite le journal du service lui-même au lieu de supposer que la correction a fonctionné. Un démarrage propre prouve seulement que systemd a accepté l’unité ; le client peut encore mourir sur un profil absent, un pair injoignable ou un certificat qui ne valide pas. Ce sont des problèmes OpenVPN ordinaires qui étaient cachés derrière l’unité masquée. Le journal indique quel profil a été chargé et si le tunnel s’est réellement établi. Si l’unité démarre et que le tunnel non, vous êtes passé à un autre problème, ce qui est un progrès.

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

Comme /run est un système de fichiers temporaire, un redémarrage efface aussi le fichier. Cela fait du redémarrage un test utile : si le service fonctionne après un redémarrage et échoue de nouveau après le déploiement suivant, le fichier est intégré à l’image.

Empêchez son retour depuis l’image

Un modèle de conteneur ou de machine virtuelle qui masque des unités de montage pendant sa construction transportera ce masque dans chaque clone. Ce qui aura besoin du système de fichiers ensuite casse, et le message accuse le montage au lieu de l’image d’où il vient. Corriger dans une instance en cours d’exécution cache le problème jusqu’à la création de l’instance suivante.

Cherchez dans le contexte de construction le nom du fichier et la commande qui le crée, puis retirez le masque du modèle et reconstruisez. Si le masque est réellement nécessaire pendant la construction, retirez-le dans la même couche qui termine la construction, afin que l’image livrée démarre proprement. Vérifiez sur un clone neuf et non sur la machine que vous avez réparée à la main. C’est le seul test qui prouve que l’image a changé.

Le symptôme à retenir est l’écart entre l’erreur et ce que vous étiez en train de configurer. Quand systemd se plaint d’un montage alors que vous démarrez un client VPN, lisez le nom de l’unité dans le message avant de lire le nom du service.