Quelque chose démarre sans cesse une unité OpenVPN : trouver la source

Une instance OpenVPN apparaît au démarrage sous un nom que vous ne reconnaissez pas, et l'arrêter fonctionne jusqu'au prochain redémarrage. Ce schéma signifie que vous avez supprimé le processus mais pas l'activation. Ce sont deux objets différents, et un seul d'entre eux est visible dans un écran d'état. Trouver l'activation demande quatre commandes en lecture seule et une décision.

Nommez d'abord l'unité exacte

Partez du nom de l'unité dans le journal, plutôt que du nom d'un fichier de profil. L'instance peut s'appeler openvpn@, openvpn-client@, openvpn-server@ ou quelque chose de spécifique à la distribution, et deviner le nom vous envoie vers le mauvais modèle. La sortie d'état nomme l'unité qui a réellement tourné, et c'est le seul nom qui compte ici. Copiez-le exactement, suffixe compris.

Les commandes suivantes décrivent cette unité sans rien modifier. systemctl show indique le chemin du fragment, le chemin source, l'état du fichier d'unité, les éventuels drop-ins et ce qui l'a déclenchée. list-dependencies --reverse montre quelles unités chargées pointent vers elle. Les deux sont en lecture seule, exécutez-les donc avant de former une théorie.

Remplacez le nom observé partout. Un nom d'exemple copié-collé est la façon la plus courante d'enquêter sur le mauvais service, et il produit des réponses assurées sur une unité qui n'a jamais tourné.

Lisez le modèle pour connaître le nom du fichier

Une unité d'instance est une expansion d'un modèle, et le modèle décide quel fichier de configuration elle lit. Une ligne de commande se terminant par un espace réservé propre à l'instance se résout en nom d'instance plus le suffixe. Si le suffixe est .conf et que l'instance s'appelle old, le fichier est old.conf. Si vous nommez l'instance old.conf, le même modèle demande old.conf.conf.

Ce détail explique une classe de doublons. Quelqu'un ajoute une seconde instance sous le mauvais nom, la première continue de tourner, et l'hôte finit avec deux tunnels et un journal déroutant.

Lisez le modèle effectif plutôt que le fichier dont vous vous souvenez l'avoir modifié. Un drop-in peut remplacer la ligne de commande, et le remplacement est ce qui s'exécute au démarrage.

Retracez comment elle entre dans la transaction de démarrage

Trois voies sont courantes : un lien wants depuis une cible, une exigence d'une autre unité ou une unité générée par un générateur de paquets. La liste des dépendances inverses couvre les deux premières comme entrées chargées du graphe. Elle ne couvre pas un minuteur, un hook ou une requête externe, et c'est pourquoi la liste est une preuve et non un audit complet.

La sortie générée sous /run/systemd/generator est un produit, pas une source. La modifier ne survit que jusqu'à la génération suivante, et c'est pourquoi un correctif appliqué là semble réussi puis revient en arrière.

Vérifiez l'entrée documentée du paquet avant de supposer où le générateur lit. Une analyse non documentée d'un répertoire est la raison habituelle pour laquelle une unité apparaît sans lien d'activation.

Supprimez l'activation, pas seulement le processus

Si l'instance est directement activée et vraiment obsolète, systemctl disable --now l'arrête et supprime le lien de démarrage en une seule étape. Vérifiez d'abord que ce tunnel n'est pas votre seul chemin administratif vers l'hôte. La commande est un exemple de cycle de vie, pas une suggestion d'arrêter chaque VPN de la machine. Lancez la vérification avant la commande, pas après.

Les deux moitiés sont séparables et souvent confondues. Désactiver n'arrête pas un service en cours, et arrêter ne supprime pas l'activation, donc une commande partielle explique un problème qui revient au démarrage.

Une unité désactivée peut encore être démarrée par une autre unité ou par une requête explicite. Quand un générateur possède l'activation, corrigez son entrée au lieu de désactiver sa sortie. Le masquage bloque plus de chemins mais peut casser des dépendances, il ne remplace donc pas la compréhension.

Vérifiez par un redémarrage, pas par un écran d'état

Rechargez systemd si les définitions d'unité ou les entrées du générateur ont changé, puis inspectez l'état résultant. Un rechargement du daemon ne pousse pas un nouveau profil dans un tunnel en cours, les deux vérifications sont donc distinctes. Planifiez un redémarrage et confirmez que l'instance reste absente pendant que le tunnel prévu fonctionne toujours.

Gardez l'ancien profil jusqu'à ce que sa propriété soit comprise, puis retirez-le via le processus prévu. Le succès est une unité absente et un chemin d'accès fonctionnel, pas une unité en échec manquant sur un écran.