Fichier PID présent, aucun tunnel : OpenVPN a-t-il jamais tourné ?

Quand le lanceur refuse de démarrer OpenVPN parce qu'un fichier PID existe déjà, la lecture naturelle est qu'un tunnel tourne quelque part. Cette lecture est fausse assez souvent pour valoir une vérification avant de supprimer quoi que ce soit. Un fichier dans un répertoire d'exécution est de la comptabilité, et la comptabilité survit aux plantages, aux redémarrages et aux arrêts interrompus qui n'ont laissé aucun processus. Deux questions tranchent le cas : y a-t-il un processus vivant, et ce processus appartient-il à cette instance.

Commencez par le service, pas par le fichier

Le refus vient généralement d'un lanceur plutôt que d'OpenVPN lui-même. Il lit un chemin, y trouve quelque chose et s'arrête avant d'analyser une configuration. La première question porte donc sur le contrat du lanceur, pas sur le tunnel.

Lisez l'unité ou le script qui a imprimé le message et notez trois choses : le chemin qu'il vérifie, le type de service qu'il déclare et s'il est responsable de l'écriture du fichier. Une unité moderne peut utiliser une supervision simple ou notify et ne jamais toucher un fichier PID, tandis qu'un ancien script init peut en créer un lui-même. Copier une vérification d'un modèle à l'autre produit exactement ce genre de refus. Déterminez quel modèle est utilisé avant d'interpréter quoi que ce soit.

C'est seulement alors que la question devient : une instance tourne-t-elle vraiment.

Vérifiez si cet identifiant appartient à votre instance

Un nombre dans un fichier prouve qu'un nombre a été écrit. Il ne prouve pas qu'un processus portant cet identifiant existe maintenant, et il ne prouve certainement pas que le processus est le vôtre, car les identifiants sont réutilisés après un redémarrage.

Comparez l'heure de démarrage du processus à l'horodatage du fichier, l'exécutable à la commande de l'unité et l'appartenance au service au nom de l'unité. Une discordance sur l'un des trois signifie que vous regardez de la comptabilité, pas un tunnel.

Sur un hôte qui exécute des conteneurs ou plusieurs espaces de noms, un identifiant peut avoir un sens dans une vue et manquer dans une autre. Ne pas voir un processus n'est pas non plus la preuve qu'il n'existe pas, si votre compte ne peut pas l'inspecter. Vérifiez depuis le contexte qu'utilise le lanceur avant de conclure.

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

Ce que le lanceur a promis de faire du fichier

PIDFile= indique au gestionnaire de services où lire l'identifiant du processus principal. Le gestionnaire n'écrit pas ce fichier, mais il supprime celui qui a survécu après l'arrêt, et c'est exactement pourquoi une sortie interrompue peut laisser un fichier.

Cette répartition des responsabilités explique deux symptômes que les gens signalent comme des bogues. Un fichier qui n'apparaît jamais signifie que le démon ou son script n'a pas réussi à l'écrire, pas que la supervision est mal configurée. Un fichier qui survit à un arrêt signifie que le chemin d'arrêt ne s'est jamais terminé.

Cela explique aussi pourquoi les recommandations actuelles suggèrent d'éviter la convention quand la supervision peut suivre le processus principal directement. Ces recommandations ne sont pas une permission de changer le type d'une unité empaquetée, car le comportement du démon au premier plan, en bifurcation ou en notification doit correspondre à ce que l'unité déclare. Changez le type sans changer le démon et vous obtenez une unité qui signale un échec pendant que le tunnel tourne, ou l'inverse. Accordez la paire, ou laissez les deux. La référence du service systemd décrit ce partage de propriété.

Arrêt propre contre sortie interrompue

Un arrêt propre demande au démon de sortir, l'attend et laisse le gestionnaire ranger sa propre comptabilité. Une sortie interrompue, un processus tué ou un redémarrage en pleine extinction sautent des parties de cette séquence, et le fichier est ce qui reste. En trouver un après un plantage vous dit que l'arrêt ne s'est pas terminé, pas que quelque chose écoute.

Comparez l'horodatage du fichier au dernier démarrage et au dernier arrêt de l'unité.

Vérifiez ensuite les preuves vivantes directement. Une socket liée au port VPN et une interface de tunnel avec une adresse sont la preuve que quelque chose tourne, d'une manière qu'un fichier texte dans un répertoire d'exécution n'est jamais. Si les deux manquent, rien ne tourne, quoi qu'affirme le fichier.

Cessez de supprimer le fichier par habitude

Le supprimer est une étape de récupération légitime une fois que vous avez établi qu'aucune instance ne le possède et que le lanceur documente ce comportement.

Comme habitude permanente avant démarrage, il défait la vérification que vous contournez. Si des fichiers périmés reviennent après chaque arrêt propre, l'écrivain et le cycle de vie de l'arrêt ne sont pas d'accord sur qui possède le chemin, et ce désaccord est le bogue qui mérite d'être corrigé.

Gardez un accès indépendant à l'hôte, démarrez une instance via son gestionnaire normal et lisez le premier résultat. La personne suivante reçoit une unité qui soit fonctionne, soit s'explique.