Ordem de encerramento dos serviços de VPN e proxy no Linux

Travamentos ao encerrar enquanto um proxy está em execução raramente são um bug de VPN, mesmo quando a VPN é a última coisa visível na tela. Os aplicativos atrás do proxy ainda esperam por um caminho que está prestes a desaparecer, e a unidade que é dona do túnel ainda não foi solicitada a fechá-lo. O que parece um serviço lento normalmente é um problema de ordem. Sequenciar resolve mais desses casos do que qualquer alteração de timeout.

Trabalhe para fora na ordem inversa: primeiro os consumidores, depois o proxy e por fim o túnel — cada um parado pelo componente que o iniciou.

Liste as unidades antes de parar qualquer coisa

Anote a unidade do aplicativo, a unidade do proxy e o dono da VPN envolvidos em uma execução normal. Inclua qualquer resolvedor ou componente auxiliar com encerramento próprio, porque são justamente esses que as pessoas esquecem às duas da manhã. Sem essa lista, o primeiro comando de parada que você digitar escolhe uma vítima ao acaso.

Nomes são evidência fraca. Um proxy de usuário, um proxy de sistema e o túnel de outra conta podem compartilhar o mesmo nome e ter ciclos de vida totalmente sem relação.

Termine o trabalho e então pare o consumidor

Uma parada planejada começa pelo aplicativo: deixe-o concluir ou cancelar suas requisições e depois pare o proxy pela unidade de serviço dele. Se o aplicativo deve continuar rodando depois que o túnel desaparecer, organize isso deliberadamente em vez de deixá-lo ligado a uma rota que está prestes a sumir.

As requisições que estavam em voo durante a parada pertencem ao registro, porque é daí que vem a tempestade de novas tentativas na próxima inicialização.

ExecStop e ExecStopPost são instrumentos diferentes

ExecStop= — é a operação de parada síncrona; ExecStopPost= — é a limpeza que roda mesmo depois de uma inicialização malsucedida. Um comando de parada que apenas envia um sinal a um processo e retorna deixa o systemd seguir adiante enquanto o consumidor ainda está descarregando dados. Tudo o que precisa acontecer de qualquer jeito pertence à variante post, e tudo o que precisa bloquear a parada pertence à síncrona. Inspecione a unidade efetiva e os arquivos drop-in dela em vez de editar um arquivo do pacote no lugar.

Um grafo de dependências ordena as tarefas de parada. Ele não transforma um script assíncrono em síncrono, nem obriga um aplicativo remoto a confirmar seus dados.

Limite a parada e saiba quanto esse limite custa

TimeoutStopSec= limita tanto o comando de parada quanto o encerramento da própria unidade, e o systemd escala para um kill forçado quando o limite expira. Escolha o valor a partir do comportamento real de descarga do aplicativo e anote o que pode ser perdido quando o limite for atingido. Um número escolhido porque a máquina deveria desligar mais rápido é um ajuste de perda de dados disfarçado.

Quando uma parada continua lenta, capture a unidade, os processos filhos dela, o intervalo do journal e o resultado do timeout. Encurtar todos os timeouts ou recorrer a um kill amplo é como paradas limpas viram estado corrompido no próximo boot.

Desconecte pelo dono e depois teste três casos

Com os consumidores parados, peça ao gerenciador que é dono do túnel para desconectar: a instância systemd, a conexão ativa do NetworkManager ou o serviço do fornecedor. Matar um processo OpenVPN não relacionado não remove necessariamente a sessão que forneceu a rota, e um proxy com política de reinício pode recriar uma requisição enquanto você desmonta o caminho. Coordene essa política com a parada planejada antes de começar.

Teste uma parada normal, uma parada com uma requisição ativa e uma parada em que o túnel falha primeiro. Uma sequência repetível com prazo vale mais que um desligamento rápido que funciona uma vez.