A Linux VPN- és proxyszolgáltatások helyes sorrendű leállítása

A leállítás alatti akadás futó proxy mellett ritkán VPN-hiba, még akkor sem, ha a VPN az utolsó dolog, ami a képernyőn látszik. A proxy mögötti alkalmazások még mindig egy hamarosan eltűnő útvonalra várnak, és az alagutat birtokló egységet még nem kérték meg a lezárására. Ami lassú szolgáltatásnak látszik, az általában sorrendi probléma. A sorrend több ilyen esetet old meg, mint bármely időkorlát-módosítás.

Kifelé haladva dolgozzon, fordított sorrendben: először a fogyasztók, aztán a proxy, aztán az alagút, és mindegyiket az a komponens állítja le, amelyik elindította.

Sorolja fel az egységeket, mielőtt bármit leállítana

Írja fel az alkalmazás egységét, a proxy egységét és a VPN tulajdonosát, amelyek egy normál futásban érintettek. Adja hozzá mindazokat a feloldókat vagy segédeket, amelyeknek saját leszerelésük van, mert éppen ezeket felejtik el az emberek hajnali kettőkor. E lista nélkül az első leállító parancs, amit beír, véletlenszerűen választ áldozatot.

A nevek gyenge bizonyítékok. Egy felhasználói proxy, egy rendszerproxy és egy másik fiók alagútja osztozhat a néven, miközben életciklusaik teljesen függetlenek.

Fejezze be a munkát, aztán állítsa le a fogyasztót

A tervezett leállítás az alkalmazással kezdődik: hagyja, hogy befejezze vagy megszakítsa a kéréseit, majd állítsa le a proxyt a szolgáltatásegységén keresztül. Ha az alkalmazásnak az alagút eltűnése után is futnia kell, rendezze ezt szándékosan, ahelyett hogy egy hamarosan eltűnő útvonalon hagyná lógni.

A leállítás alatt úton lévő kérések a feljegyzésbe tartoznak, mert innen jön az újrapróbálkozások vihara a következő indításkor.

Az ExecStop és az ExecStopPost különböző eszközök

Az ExecStop= a szinkron leállítási művelet; az ExecStopPost= olyan takarítás, amely sikertelen indítás után is lefut. Az a leállító parancs, amely csak jelet küld egy folyamatnak és visszatér, engedi a systemd-t továbbmenni, miközben a fogyasztó még kiürül. Minden, aminek mindenképpen meg kell történnie, az utólagos változatba tartozik, és minden, aminek blokkolnia kell a leállítást, a szinkronba. Vizsgálja meg az effektív egységet és annak kiegészítéseit, ahelyett hogy egy csomagfájlt a helyén szerkesztene.

Egy függőségi gráf rendezi a leállítási feladatokat. Nem tesz aszinkron szkriptet szinkronná, és nem kényszerít egy távoli alkalmazást arra, hogy elmentse az adatait.

Határolja be a leállítást, és tudja, mennyibe kerül a határ

A TimeoutStopSec= korlátozza a leállító parancsot és a szolgáltatás saját befejezését is, és a systemd erőszakos ölésre vált, amikor a korlát lejár. Az értéket az alkalmazás valós kiürülési viselkedése alapján válassza, és írja fel, mi veszhet el, amikor eléri. Az a szám, amelyet azért választottak, mert a gépnek gyorsabban kell kikapcsolnia, álcázott adatvesztési beállítás.

Ha a leállítás még mindig lassú, rögzítse az egységet, annak gyermekfolyamatait, a napló intervallumát és az időkorlát eredményét. Minden időkorlát lerövidítése vagy széles körű öléshez nyúlás az az út, amelyen a tiszta leállások a következő indításkor sérült állapottá válnak.

A tulajdonoson keresztül bontsa a kapcsolatot, majd három esetet teszteljen

Amikor a fogyasztók leálltak, kérje meg az alagutat birtokló kezelőt a kapcsolat bontására: a systemd példányt, a NetworkManager aktív kapcsolatát vagy a szállító szolgáltatását. Egy nem kapcsolódó OpenVPN-folyamat megölése nem feltétlenül távolítja el azt a munkamenetet, amely az útvonalat adta, és az újraindítási szabályzattal rendelkező proxy újra létrehozhat egy kérést, miközben az útvonalat bontja. Egyeztesse ezt a szabályzatot a tervezett leállítással, mielőtt elkezdi.

Teszteljen egy normál leállítást, egy aktív kéréssel járó leállítást és egy olyat, amelyben az alagút hibázik először. A határidővel ellátott ismételhető sorrend jobb, mint az egyszer működő gyors leállás.