Aturar els serveis VPN i de proxy de Linux en l'ordre correcte

Els tancaments que es pengen mentre s'executa un proxy poques vegades són un error de la VPN, fins i tot quan la VPN és l'última cosa que es veu a la pantalla. Les aplicacions darrere del proxy encara esperen un camí que està a punt de desaparèixer, i la unitat que posseeix el túnel encara no ha estat demanada per tancar-lo. El que sembla un servei lent sol ser un problema d'ordre. L'ordre resol més d'aquests casos que qualsevol canvi de temps d'espera.

Treballeu cap enfora en ordre invers: primer els consumidors, després el proxy, després el túnel, i cada un l'atura el component que el va iniciar.

Llista les unitats abans d'aturar res

Anoteu la unitat de l'aplicació, la unitat del proxy i el propietari de la VPN implicats en una execució normal. Afegiu qualsevol resolutor o auxiliar amb desmuntatge propi, perquè aquests són els que la gent oblida a les dues de la matinada. Sense aquesta llista, la primera ordre d'aturar que escriviu tria una víctima a l'atzar.

Els noms són una prova feble. Un proxy d'usuari, un proxy de sistema i el túnel d'un altre compte poden compartir nom mentre tenen cicles de vida completament sense relació.

Acaba la feina i després atura el consumidor

Una aturada planificada comença per l'aplicació: deixeu-la acabar o cancel·lar les seves peticions, i després atureu el proxy a través de la seva unitat de servei. Si l'aplicació ha de continuar funcionant quan el túnel desaparegui, organitzeu-ho deliberadament en lloc de deixar-la enganxada a una ruta que està a punt de desaparèixer.

Les peticions que estaven en curs durant l'aturada han de constar al registre, perquè d'aquí ve la tempesta de reintents a la propera arrencada.

ExecStop i ExecStopPost són instruments diferents

ExecStop= és l'operació d'aturada síncrona; ExecStopPost= és la neteja que s'executa fins i tot després d'una arrencada fallida. Una ordre d'aturada que només envia un senyal a un procés i torna deixa que systemd continuï mentre el consumidor encara buida. Tot el que ha de passar en qualsevol cas pertany a la variant posterior, i tot el que ha de bloquejar l'aturada pertany a la síncrona. Inspeccioneu la unitat efectiva i els seus afegits en lloc d'editar un fitxer del paquet al seu lloc.

Un graf de dependències ordena les tasques d'aturada. No converteix un script asíncron en síncron, ni fa que una aplicació remota confirmi les seves dades.

Limita l'aturada i sàpigues què costa el límit

TimeoutStopSec= limita tant l'ordre d'aturada com la terminació pròpia del servei, i systemd escala a una mort forçosa quan el límit expira. Trieu el valor a partir del comportament real de buidatge de l'aplicació, i anoteu què es pot perdre quan s'assoleix. Un número triat perquè la màquina ha d'apagar-se més de pressa és un paràmetre de pèrdua de dades disfressat.

Quan una aturada encara és lenta, captureu la unitat, els seus processos fills, l'interval del registre i el resultat del temps d'espera. Escurçar cada temps d'espera o recórrer a una mort àmplia és com les aturades netes es converteixen en estat corrupte a la propera arrencada.

Desconnecta a través del propietari i després prova tres casos

Un cop els consumidors han caigut, demaneu al gestor que posseeix el túnel que es desconnecti: la instància de systemd, la connexió activa de NetworkManager o el servei del proveïdor. Matar un procés OpenVPN no relacionat no elimina necessàriament la sessió que va proporcionar la ruta, i un proxy amb política de reinici pot recrear una petició mentre desmunteu el camí. Coordineu aquesta política amb l'aturada planificada abans de començar.

Proveu una aturada normal, una aturada amb una petició activa i una aturada en què el túnel falla primer. Una seqüència repetible amb un termini supera un tancament ràpid que funciona una vegada.