Arrêter les services VPN et proxy de Linux dans le bon ordre

Les arrêts qui se bloquent pendant qu'un proxy tourne sont rarement un défaut du VPN, même quand le VPN est la dernière chose visible à l'écran. Les applications derrière le proxy attendent encore un chemin sur le point de disparaître, et l'unité qui possède le tunnel n'a pas encore été priée de le fermer. Ce qui ressemble à un service lent est généralement un problème d'ordre. L'ordre résout plus de ces cas que n'importe quel changement de délai.

Travaillez vers l'extérieur dans l'ordre inverse : d'abord les consommateurs, puis le proxy, puis le tunnel, chacun arrêté par le composant qui l'a démarré.

Listez les unités avant d'arrêter quoi que ce soit

Notez l'unité de l'application, l'unité du proxy et le propriétaire du VPN impliqués dans une exécution normale. Ajoutez tout résolveur ou assistant ayant son propre démontage, car ce sont eux que les gens oublient à deux heures du matin. Sans cette liste, la première commande d'arrêt que vous tapez choisit une victime au hasard.

Les noms sont une preuve faible. Un proxy utilisateur, un proxy système et le tunnel d'un autre compte peuvent partager un nom tout en ayant des cycles de vie entièrement indépendants.

Terminez le travail, puis arrêtez le consommateur

Un arrêt planifié commence par l'application : laissez-la terminer ou annuler ses requêtes, puis arrêtez le proxy via son unité de service. Si l'application doit continuer à fonctionner après la disparition du tunnel, organisez-le délibérément au lieu de la laisser accrochée à une route sur le point de disparaître.

Les requêtes en cours pendant l'arrêt doivent figurer dans le journal, car c'est de là que vient la tempête de nouvelles tentatives au prochain démarrage.

ExecStop et ExecStopPost sont des instruments différents

ExecStop= est l'opération d'arrêt synchrone ; ExecStopPost= est un nettoyage qui s'exécute même après un démarrage échoué. Une commande d'arrêt qui se contente d'envoyer un signal à un processus et revient laisse systemd avancer pendant que le consommateur vide encore. Tout ce qui doit se produire quoi qu'il arrive appartient à la variante postérieure, et tout ce qui doit bloquer l'arrêt appartient à la variante synchrone. Inspectez l'unité effective et ses ajouts au lieu de modifier un fichier du paquet sur place.

Un graphe de dépendances ordonne les tâches d'arrêt. Il ne transforme pas un script asynchrone en script synchrone, et il ne force pas une application distante à valider ses données.

Borner l'arrêt et savoir ce que coûte la borne

TimeoutStopSec= limite à la fois la commande d'arrêt et la terminaison propre du service, et systemd passe à un arrêt forcé quand la limite expire. Choisissez la valeur d'après le comportement réel de vidage de l'application, et notez ce qui peut être perdu lorsqu'elle se déclenche. Un nombre choisi parce que la machine doit s'éteindre plus vite est un réglage de perte de données déguisé.

Quand un arrêt reste lent, capturez l'unité, ses processus enfants, l'intervalle du journal et le résultat du délai. Raccourcir chaque délai ou recourir à un arrêt massif est la façon dont des arrêts propres deviennent un état corrompu au démarrage suivant.

Déconnectez via le propriétaire, puis testez trois cas

Une fois les consommateurs arrêtés, demandez au gestionnaire qui possède le tunnel de se déconnecter : l'instance systemd, la connexion active de NetworkManager ou le service du fournisseur. Tuer un processus OpenVPN sans rapport ne supprime pas forcément la session qui a fourni la route, et un proxy doté d'une politique de redémarrage peut recréer une requête pendant que vous démontez le chemin. Coordonnez cette politique avec l'arrêt planifié avant de commencer.

Testez un arrêt normal, un arrêt avec une requête active et un arrêt où le tunnel échoue en premier. Une séquence reproductible avec une échéance vaut mieux qu'un arrêt rapide qui ne fonctionne qu'une fois.