Kolejność zatrzymywania usług VPN i proxy w systemie Linux

Zawieszenia przy zatrzymywaniu, gdy działa proxy, rzadko są błędem VPN, nawet gdy VPN jest ostatnią rzeczą widoczną na ekranie. Aplikacje za proxy wciąż czekają na ścieżkę, która zaraz zniknie, a jednostka będąca właścicielem tunelu nie została jeszcze poproszona o jego zamknięcie. To, co wygląda na wolno działającą usługę, zwykle jest problemem kolejności. Uporządkowanie rozwiązuje więcej takich przypadków niż jakakolwiek zmiana limitu czasu.

Idź na zewnątrz w odwrotnej kolejności: najpierw konsumenci, potem proxy, a na końcu tunel — każdy zatrzymywany przez komponent, który go uruchomił.

Sporządź listę jednostek, zanim cokolwiek zatrzymasz

Zapisz jednostkę aplikacji, jednostkę proxy i właściciela VPN biorących udział w normalnym uruchomieniu. Dodaj dowolny resolver lub komponent pomocniczy mający własne zamykanie, bo to właśnie one bywają zapominane o drugiej w nocy. Bez tej listy pierwsza wpisana komenda zatrzymania wybierze ofiarę losowo.

Nazwy są słabym dowodem. Proxy użytkownika, proxy systemowe i tunel innego konta mogą dzielić tę samą nazwę, mając całkowicie niepowiązane cykle życia.

Najpierw dokończ pracę, potem zatrzymaj konsumenta

Planowane zatrzymanie zaczyna się od aplikacji: pozwól jej dokończyć lub anulować żądania, a następnie zatrzymaj proxy przez jego jednostkę usługi. Jeśli aplikacja ma działać dalej po zniknięciu tunelu, zorganizuj to celowo, zamiast zostawiać ją przypiętą do trasy, która zaraz zniknie.

Żądania, które były w locie podczas zatrzymania, należą do zapisu, bo stamtąd bierze się burza ponowień przy następnym starcie.

ExecStop i ExecStopPost to różne narzędzia

ExecStop= — to synchroniczna operacja zatrzymania; ExecStopPost= — to sprzątanie, które wykonuje się nawet po nieudanym starcie. Komenda zatrzymania, która jedynie sygnalizuje procesowi i wraca, pozwala systemd przejść dalej, podczas gdy konsument wciąż opróżnia bufory. Wszystko, co musi się wydarzyć niezależnie od wszystkiego, należy do wariantu po zatrzymaniu, a wszystko, co musi blokować zatrzymanie, należy do wariantu synchronicznego. Sprawdzaj obowiązującą jednostkę i jej pliki drop-in, zamiast edytować plik pakietu na miejscu.

Graf zależności porządkuje zadania zatrzymania. Nie zamienia skryptu asynchronicznego w synchroniczny ani nie zmusza zdalnej aplikacji do zatwierdzenia danych.

Ogranicz zatrzymanie i wiedz, ile ten limit kosztuje

TimeoutStopSec= ogranicza zarówno komendę zatrzymania, jak i własne zakończenie usługi, a gdy limit wygaśnie, systemd przechodzi do wymuszonego zabicia. Wybierz wartość na podstawie rzeczywistego zachowania aplikacji przy opróżnianiu i zapisz, co może zostać utracone, gdy limit zadziała. Liczba wybrana dlatego, że maszyna ma się wyłączyć szybciej, to ustawienie utraty danych pod inną nazwą.

Gdy zatrzymanie nadal jest wolne, zapisz jednostkę, jej procesy potomne, interwał dziennika i wynik limitu czasu. Skracanie wszystkich limitów lub sięganie po szerokie zabijanie to sposób, w jaki czyste zatrzymania zamieniają się w uszkodzony stan przy następnym rozruchu.

Rozłącz się przez właściciela, potem przetestuj trzy przypadki

Gdy konsumenci są zatrzymani, poproś menedżera będącego właścicielem tunelu o rozłączenie: instancję systemd, aktywne połączenie NetworkManager lub usługę dostawcy. Zabicie niepowiązanego procesu OpenVPN niekoniecznie usuwa sesję, która dostarczyła trasę, a proxy z polityką ponownego uruchamiania może odtworzyć żądanie, gdy demontujesz ścieżkę. Uzgodnij tę politykę z planowanym zatrzymaniem, zanim zaczniesz.

Przetestuj zwykłe zatrzymanie, zatrzymanie z aktywnym żądaniem i zatrzymanie, w którym tunel zawodzi pierwszy. Powtarzalna sekwencja z terminem jest lepsza niż szybkie wyłączenie, które działa raz.