Identifier un assistant VPN sur Mac avant de tuer le processus

Traitez un message concernant un assistant déjà en cours d'exécution comme un indice sur le cycle de vie, et non comme l'autorisation de commencer à tuer des processus. L'étape dangereuse n'est pas l'arrêt lui-même mais l'identification qui le précède, car plusieurs composants aux noms similaires peuvent coexister sur un Mac et un seul d'entre eux possède la connexion. Construisez d'abord la fiche d'identité. Décidez ensuite si un arrêt est vraiment la bonne action.

Construisez une fiche d'identité avant d'agir

Quatre faits rendent un processus identifiable : le PID actuel avec son heure de démarrage, l'exécutable et le produit auxquels il appartient, le contexte utilisateur ou de privilèges sous lequel il s'exécute, et tout ce qui l'a lancé. ps -o pid,ppid,user,etime,command -p 1234 vous donne les trois premiers sur une ligne, y compris depuis combien de temps le processus est vivant. Activity Monitor affiche les mêmes informations avec un visage plus aimable. Ajoutez le contrôleur, c'est-à-dire l'application ou le service chargé de le démarrer et de l'arrêter. Avec ces quatre éléments, un processus cesse d'être un nom et devient un objet sur lequel vous pouvez raisonner.

Si l'un des quatre est inconnu, arrêtez-vous là. Un composant inconnu est une question pour l'éditeur ou l'administrateur, pas une expérience.

Le PID d'un ancien journal appartient désormais à quelqu'un d'autre

Les identifiants de processus sont recyclés, et un numéro copié dans le journal d'hier peut désormais pointer vers quelque chose de totalement sans rapport. Comparez l'heure de démarrage à l'horodatage du journal avant de tirer la moindre conclusion. Il en va de même pour un nom court : deux versions d'un même produit peuvent livrer des assistants aux noms identiques et aux usages différents. L'identité est le tuple, jamais le numéro seul.

Séparez les rôles avant de toucher à quoi que ce soit d'autre. Le client d'une seule connexion, un assistant partagé servant plusieurs applications et un serveur acceptant les sessions d'autres personnes ressemblent tous à un processus en arrière-plan dans une liste. Un seul d'entre eux peut être arrêté sans conséquences que vous n'avez pas envisagées.

Arrêtez via le propriétaire, pas via le signal

Commencez par le contrôle qui possède la chose : le bouton Déconnecter de la connexion, la commande d'arrêt prise en charge du service ou l'action propre de l'agent de gestion. Ces chemins exécutent le démontage attendu par le produit, qui comprend la suppression des routes et la fermeture du périphérique de tunnel. Un signal saute tout cela et laisse un état derrière lui.

Observez ce qui reste ensuite. Un processus qui reste résident attend peut-être la prochaine connexion, ce qui est un choix de conception et non un arrêt raté.

Pourquoi un superviseur relance ce que vous avez tué

Si un démon de lancement ou une politique de connexion automatique veut que le tunnel soit actif, tuer le processus n'exprime rien. Le superviseur voit la sortie et le redémarre, parfois avant que vous ayez fini de lire le journal.

Trouvez le superviseur avant de l'affronter. launchctl list affiche les tâches chargées et leurs étiquettes, et une tâche avec un réglage de maintien en vie redémarre à la sortie par conception. L'action correcte consiste à changer l'intention : déchargez la tâche, désactivez la politique de connexion automatique ou demandez à l'administrateur de le faire. Forcer la fermeture est un autre outil avec une autre signification, et il relève d'une procédure de récupération documentée pour un processus bloqué, non de la gestion courante des connexions.

Consignez l'événement du cycle de vie, pas le meurtre

Notez l'identité du composant, la version du client, le premier événement pertinent du cycle de vie et ce que vous avez fait. L'événement compte plus que l'action, car deux instances apparaissant à la connexion sont un problème d'ordre de démarrage qui se reproduira. Une fiche nommant l'exécutable et son contrôleur permet à la personne suivante de le reproduire.

Vérifiez ensuite l'état visé : le service dont l'utilisateur avait besoin et la ressource privée qu'il atteint. Évitez le pipeline qui cherche une sous-chaîne et tue de force chaque correspondance, car il écarte tout ce qui précède et détruit généralement la preuve de la raison pour laquelle deux instances existaient. Si le processus revient sans cesse, le constat est un défaut de configuration ou d'ordre, et le correctif revient à qui possède le comportement de démarrage du client.