Apagar os servizos de VPN e proxy de Linux na orde correcta

Os apagados que se colgan mentres corre un proxy raramente son un fallo da VPN, mesmo cando a VPN é o último que se ve na pantalla. As aplicacións detrás do proxy seguen agardando un camiño que está a piques de desaparecer, e á unidade dona do túnel aínda non se lle pediu que o peche. O que parece un servizo lento adoita ser un problema de orde. A orde resolve máis destes casos que calquera cambio no tempo de espera.

Traballa cara a fóra en orde inversa: primeiro os consumidores, despois o proxy, despois o túnel, cada un detido polo compoñente que o iniciou.

Enumera as unidades antes de deter calquera cousa

Anota a unidade da aplicación, a unidade do proxy e o propietario da VPN implicados nunha execución normal. Engade calquera resolvedor ou axudante co seu propio desmontaxe, porque son eses os que a xente esquece ás dúas da madrugada. Sen esa lista, o primeiro comando de parada que escribas escolle unha vítima ao azar.

Os nomes son unha proba fraca. Un proxy de usuario, un proxy de sistema e o túnel doutra conta poden compartir nome mentres os seus ciclos de vida non teñen ningunha relación.

Remata o traballo e despois detén o consumidor

Unha parada planificada comeza pola aplicación: déixaa rematar ou cancelar as súas peticións e despois detén o proxy mediante a súa unidade de servizo. Se a aplicación debe seguir funcionando cando o túnel desapareza, dispón iso a propósito en lugar de deixala enganchada a unha ruta que está a piques de desaparecer.

As peticións que estaban en curso durante a parada deben quedar no rexistro, porque de aí vén a tormenta de reintentos no seguinte arranque.

ExecStop e ExecStopPost son instrumentos distintos

ExecStop= é a operación de parada síncrona; ExecStopPost= é a limpeza que se executa mesmo despois dun arranque fallido. Un comando de parada que só envía un sinal a un proceso e volve deixa que systemd siga adiante mentres o consumidor aínda baleira. Todo o que debe ocorrer en calquera caso pertence á variante posterior, e todo o que debe bloquear a parada pertence á síncrona. Inspecciona a unidade efectiva e os seus engadidos en lugar de editar un ficheiro do paquete no seu sitio.

Un grafo de dependencias ordena os traballos de parada. Non converte un script asíncrono en síncrono, nin fai que unha aplicación remota confirme os seus datos.

Limita a parada e sabe canto custa o límite

TimeoutStopSec= limita tanto o comando de parada como a terminación propia do servizo, e systemd pasa a un peche forzado cando o límite expira. Escolle o valor segundo o comportamento real de baleirado da aplicación e anota que se pode perder cando se alcance. Un número escollido porque a máquina debe apagarse máis rápido é un axuste de perda de datos disfrazado.

Cando unha parada segue sendo lenta, captura a unidade, os seus procesos fillos, o intervalo do rexistro e o resultado do tempo de espera. Acurtar todos os tempos de espera ou recorrer a un peche masivo é como as paradas limpas se converten en estado corrupto no seguinte arranque.

Desconecta a través do propietario e despois proba tres casos

Unha vez que os consumidores están abaixo, pide ao xestor dono do túnel que se desconecte: a instancia de systemd, a conexión activa de NetworkManager ou o servizo do provedor. Matar un proceso de OpenVPN non relacionado non elimina necesariamente a sesión que forneceu a ruta, e un proxy con política de reinicio pode recrear unha petición mentres desmontas o camiño. Coordena esa política coa parada planificada antes de comezar.

Proba unha parada normal, unha parada cunha petición activa e unha parada na que o túnel falla primeiro. Unha secuencia repetible cun prazo supera un apagado rápido que funciona unha vez.