status=200/CHDIR : systemd n'a jamais lancé OpenVPN

Le service échoue, les journaux mentionnent un spawn et un répertoire, et le premier réflexe est de vérifier la configuration VPN. Rien n'a encore été lu dans ce fichier. systemd a échoué pendant la préparation du processus, avant l'exécution du binaire, donc aucun analyseur, aucun certificat et aucun hôte distant n'a été consulté. Lire le code de statut comme une affirmation sur systemd plutôt que sur OpenVPN est ce qui transforme cela en enquête courte.

Lisez le code de statut avant l'application

Le code numérique après le nom du service nomme l'étape qui a échoué. Un échec de répertoire est signalé comme statut CHDIR, tandis qu'un binaire qui n'a pas pu être exécuté est un code complètement différent. Les deux se ressemblent dans une ligne de résumé et n'ont rien en commun dans leurs causes.

Cette distinction compte parce que les correctifs se trouvent dans des fichiers différents. Un échec CHDIR concerne un chemin et la vision qu'en a le service. Un échec exec concerne le binaire, son interpréteur ou un montage sans rapport. Changer le remote VPN, la liste de chiffrements ou le chemin du certificat ne peut résoudre ni l'un ni l'autre.

Confirmez que l'échec se produit au démarrage et non après une exécution réussie. Si le service fonctionnait hier et échoue maintenant à la même étape, quelque chose a changé dans le répertoire, ses permissions ou l'unité elle-même, et ce changement est la preuve à rechercher.

Demandez à l'unité où elle veut être

Lisez l'unité effective plutôt que le fichier que vous croyez installé, car des drop-ins peuvent remplacer le répertoire de travail sans que vous ayez jamais modifié l'unité principale. La sortie de show répond directement à la question :

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

Pour le modèle du serveur upstream, le répertoire de travail est le répertoire de configuration du serveur et le nom d'instance sélectionne le profil à l'intérieur. Une instance nommée branch attend donc son propre fichier dans ce même répertoire, et un profil placé ailleurs ne satisfait pas du tout l'exigence de répertoire de travail.

Comparez ce que l'unité demande avec ce qui existe. Un chemin qui existait auparavant, un lien symbolique qui pointe désormais ailleurs ou un nom d'instance qui ne correspond plus à un répertoire sont des changements ordinaires qui produisent exactement cet échec.

Vérifiez le chemin tel que le service le voit

Votre shell et le service ne partagent pas la même vue du système de fichiers. Un répertoire racine ou une image racine configurés changent ce que signifie un chemin absolu à l'intérieur de l'unité, et un chemin manifestement présent sur l'hôte peut être absent dans cet espace de noms. Lisez les réglages de l'unité avant de vous fier à un test manuel.

Les permissions aggravent le problème. Le service s'exécute sous un utilisateur précis, et cet utilisateur doit pouvoir traverser chaque répertoire parent pour atteindre la cible, et pas seulement lire la cible elle-même. Un répertoire lisible par root et non traversable par l'utilisateur du service produit un échec qui ressemble à un chemin manquant.

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

Les réglages de durcissement font aussi partie du tableau. Une unité qui masque les répertoires personnels ou rend une partie du système de fichiers en lecture seule fait exactement ce pour quoi elle a été configurée, et le répertoire de travail doit se trouver là où le sandbox l'expose encore.

Corrigez le propriétaire, puis attendez une autre erreur

Corrigez la disposition ou l'unité via celui qui possède cette configuration. Déplacer un profil dans le répertoire attendu est un correctif légitime lorsque la disposition est mauvaise, mais cela n'explique pas un répertoire dans lequel on ne peut pas entrer, donc ne le traitez pas comme la réponse générale.

Résistez au raccourci d'élargir les permissions sur l'arbre de configuration ou de supprimer le sandbox. Les deux font disparaître le symptôme tout en supprimant les protections placées là volontairement, et la prochaine panne sera plus difficile à interpréter.

Redémarrez l'instance et lisez l'événement suivant au lieu de supposer le succès. L'erreur suivante probable est qu'OpenVPN ne peut pas ouvrir son fichier de configuration, ce qui est un progrès : le répertoire de travail a été atteint et l'analyseur tourne désormais. Suivez de là le mappage réel des fichiers de l'unité au lieu de revenir au dépannage réseau.

La référence d'exécution de systemd définit comment le répertoire de travail est interprété avec les répertoires racine et l'isolation. Le schéma à retenir est simple : chaque code de statut nomme une étape différente, et seules les erreurs propres à l'application décrivent l'application.