Apagar los servicios de VPN y proxy de Linux en el orden correcto

Los apagones que se cuelgan mientras corre un proxy rara vez son un fallo de la VPN, incluso cuando la VPN es lo último que se ve en pantalla. Las aplicaciones detrás del proxy siguen esperando un camino que está a punto de desaparecer, y a la unidad dueña del túnel todavía no se le ha pedido cerrarlo. Lo que parece un servicio lento suele ser un problema de orden. El orden resuelve más de estos casos que cualquier cambio en el tiempo de espera.

Trabaje hacia fuera en orden inverso: primero los consumidores, luego el proxy, luego el túnel, cada uno detenido por el componente que lo inició.

Enumere las unidades antes de detener cualquier cosa

Anote la unidad de la aplicación, la unidad del proxy y el propietario de la VPN implicados en una ejecución normal. Añada cualquier resolutor o ayudante con su propio desmontaje, porque esos son los que la gente olvida a las dos de la madrugada. Sin esa lista, el primer comando de parada que escriba elige una víctima al azar.

Los nombres son una prueba débil. Un proxy de usuario, un proxy de sistema y el túnel de otra cuenta pueden compartir nombre mientras sus ciclos de vida no tienen ninguna relación.

Termine el trabajo y luego detenga al consumidor

Una parada planificada empieza por la aplicación: déjela terminar o cancelar sus peticiones y luego detenga el proxy mediante su unidad de servicio. Si la aplicación debe seguir funcionando cuando el túnel desaparezca, dispóngalo a propósito en lugar de dejarla enganchada a una ruta que está a punto de desaparecer.

Las peticiones que estaban en curso durante la parada deben quedar en el registro, porque de ahí viene la tormenta de reintentos en el siguiente arranque.

ExecStop y ExecStopPost son instrumentos distintos

ExecStop= es la operación de parada síncrona; ExecStopPost= es la limpieza que se ejecuta incluso después de un arranque fallido. Un comando de parada que solo envía una señal a un proceso y vuelve deja que systemd continúe mientras el consumidor todavía vacía. Todo lo que debe ocurrir en cualquier caso pertenece a la variante posterior, y todo lo que debe bloquear la parada pertenece a la síncrona. Inspeccione la unidad efectiva y sus añadidos en lugar de editar un archivo del paquete en su sitio.

Un grafo de dependencias ordena los trabajos de parada. No convierte un script asíncrono en síncrono, ni hace que una aplicación remota confirme sus datos.

Acote la parada y sepa cuánto cuesta el límite

TimeoutStopSec= limita tanto el comando de parada como la terminación propia del servicio, y systemd escala a un cierre forzoso cuando el límite expira. Elija el valor según el comportamiento real de vaciado de la aplicación y anote qué puede perderse cuando se alcance. Un número elegido porque la máquina debe apagarse más rápido es un ajuste de pérdida de datos disfrazado.

Cuando una parada sigue siendo lenta, capture la unidad, sus procesos hijos, el intervalo del registro y el resultado del tiempo de espera. Acortar todos los tiempos de espera o recurrir a un cierre masivo es cómo las paradas limpias se convierten en estado corrupto en el siguiente arranque.

Desconecte a través del propietario y luego pruebe tres casos

Una vez que los consumidores están abajo, pida al gestor dueño del túnel que se desconecte: la instancia de systemd, la conexión activa de NetworkManager o el servicio del proveedor. Matar un proceso de OpenVPN no relacionado no elimina necesariamente la sesión que proporcionó la ruta, y un proxy con política de reinicio puede recrear una petición mientras desmonta el camino. Coordine esa política con la parada planificada antes de empezar.

Pruebe una parada normal, una parada con una petición activa y una parada en la que el túnel falla primero. Una secuencia repetible con plazo supera un apagado rápido que funciona una vez.