Ordinea opririi serviciilor VPN și proxy în Linux

Blocajele la oprire în timp ce rulează un proxy sunt rareori o eroare de VPN, chiar și când VPN-ul este ultimul lucru vizibil pe ecran. Aplicațiile din spatele proxy-ului așteaptă încă o cale care e pe punctul de a dispărea, iar unitatea care deține tunelul nu a fost încă rugată să îl închidă. Ceea ce pare un serviciu lent este de obicei o problemă de ordine. Secvențierea rezolvă mai multe astfel de cazuri decât orice schimbare de timeout.

Mergeți spre exterior în ordine inversă: mai întâi consumatorii, apoi proxy-ul, apoi tunelul — fiecare oprit de componenta care l-a pornit.

Faceți lista unităților înainte de a opri ceva

Notați unitatea aplicației, unitatea proxy-ului și proprietarul VPN-ului implicați într-o pornire normală. Adăugați orice resolver sau componentă auxiliară cu propria închidere, fiindcă exact pe ele le uită lumea la două noaptea. Fără acea listă, prima comandă de oprire pe care o tastați alege o victimă la întâmplare.

Numele sunt o dovadă slabă. Un proxy de utilizator, un proxy de sistem și tunelul altui cont pot împărtăși același nume, având cicluri de viață complet nelegate.

Terminați mai întâi lucrul, apoi opriți consumatorul

O oprire planificată începe cu aplicația: lăsați-o să își termine sau să își anuleze cererile, apoi opriți proxy-ul prin unitatea sa de serviciu. Dacă aplicația trebuie să ruleze în continuare după ce tunelul dispare, organizați asta deliberat, în loc să o lăsați atașată de o rută care e pe punctul de a dispărea.

Cererile care erau în zbor în timpul opririi aparțin înregistrării, fiindcă de acolo vine furtuna de reîncercări la următoarea pornire.

ExecStop și ExecStopPost sunt instrumente diferite

ExecStop= — este operația sincronă de oprire; ExecStopPost= — este o curățare care rulează chiar și după o pornire eșuată. O comandă de oprire care doar trimite un semnal unui proces și revine lasă systemd să meargă mai departe în timp ce consumatorul încă își golește datele. Tot ce trebuie să se întâmple indiferent de situație aparține variantei post, iar tot ce trebuie să blocheze oprirea aparține celei sincrone. Inspectați unitatea efectivă și fișierele ei drop-in în loc să editați un fișier din pachet pe loc.

Un graf de dependențe ordonează sarcinile de oprire. Nu transformă un script asincron într-unul sincron și nu obligă o aplicație de la distanță să își confirme datele.

Limitați oprirea și știți cât costă această limită

TimeoutStopSec= limitează atât comanda de oprire, cât și terminarea proprie a serviciului, iar când limita expiră, systemd trece la o ucidere forțată. Alegeți valoarea după comportamentul real al aplicației la golire și notați ce se poate pierde când limita se atinge. Un număr ales pentru că mașina ar trebui să se oprească mai repede este o setare de pierdere de date sub alt nume.

Când oprirea este încă lentă, capturați unitatea, procesele ei copil, intervalul jurnalului și rezultatul timeout-ului. Scurtarea tuturor timeout-urilor sau recurgerea la o ucidere largă este felul în care opririle curate se transformă în stare coruptă la următoarea pornire.

Deconectați-vă prin proprietar, apoi testați trei cazuri

După ce consumatorii sunt opriți, rugați managerul care deține tunelul să se deconecteze: instanța systemd, conexiunea activă NetworkManager sau serviciul furnizorului. Uciderea unui proces OpenVPN nelegat nu elimină neapărat sesiunea care a furnizat ruta, iar un proxy cu politică de repornire poate recrea o cerere în timp ce demontați calea. Coordonați acea politică cu oprirea planificată înainte de a începe.

Testați o oprire normală, o oprire cu o cerere activă și o oprire în care tunelul cedează primul. O secvență repetabilă cu un termen limită bate o oprire rapidă care funcționează o singură dată.