Rekkjefølgja for nedstenging av VPN- og proksytenester i Linux

Henging under nedstenging medan ein proksy køyrer er sjeldan ein VPN-feil, sjølv når VPN-en er det siste som synest på skjermen. Applikasjonar bak proksyen ventar framleis på ein bane som er i ferd med å forsvinne, og eininga som eig tunnelen er enno ikkje beden om å lukke han. Det som ser ut som ei treg teneste, er vanlegvis eit rekkjefølgjeproblem. Rekkjefølgje løyser fleire av desse enn kvar einaste endring av tidsavbrot.

Arbeid utover i omvend rekkjefølgje: forbrukarane fyrst, deretter proksyen, og til slutt tunnelen — kvar stoppa av komponenten som starta han.

Lag lista over einingar før du stoppar noko

Skriv ned applikasjonseininga, proksyeininga og VPN-eigaren som er involvert i ein normal køyring. Legg til kvar resolver eller hjelpekomponent med eiga nedstenging, for det er nettopp dei folk gløymer klokka to om natta. Utan den lista vel den fyrste stoppkommandoen du skriv eit tilfeldig offer.

Namn er svakt prov. Ein brukarproksy, ein systemproksy og tunnelen til ein annan konto kan dele same namn, men ha heilt urelaterte livssyklusar.

Fullfør arbeidet, og stopp deretter forbrukaren

Ein planlagd stopp byrjar med applikasjonen: la han fullføre eller avbryte førespurnadene sine, og stopp deretter proksyen gjennom tenesteeininga. Viss applikasjonen skal halde fram å køyre etter at tunnelen er borte, ordne det medvite i staden for å la han henge på ei rute som er i ferd med å forsvinne.

Førespurnader som var undervegs under stoppen høyrer heime i journalen, for det er derfrå stormen av nye forsøk kjem ved neste oppstart.

ExecStop og ExecStopPost er ulike instrument

ExecStop= — er den synkrone stoppoperasjonen; ExecStopPost= — er opprydding som køyrer sjølv etter ein mislukka oppstart. Ein stoppkommando som berre sender eit signal til ein prosess og returnerer, lèt systemd gå vidare medan forbrukaren framleis tømmer. Alt som må skje uansett høyrer til post-varianten, og alt som må blokkere stoppen høyrer til den synkrone. Undersøk den effektive eininga og drop-in-filene hennar i staden for å redigere ei pakkefil på staden.

Ein avhengigheitsgraf ordnar stoppjobbar. Han gjer ikkje eit asynkront skript synkront, og han tvingar ikkje ein ekstern applikasjon til å stadfeste dataa sine.

Avgrens stoppen og vit kva avgrensinga kostar

TimeoutStopSec= avgrensar både stoppkommandoen og tenesta si eiga avslutning, og systemd eskalerer til ein tvinga kill når grensa går ut. Vel verdien ut frå den faktiske tømjeåtferda til applikasjonen, og skriv ned kva som kan gå tapt når grensa slår inn. Eit tal valt fordi maskinen bør slåast av raskare, er ei innstilling for datatap i forkledning.

Når ein stopp framleis er treg, registrer eininga, barneprosessane, journalintervallet og tidsavbrotresultatet. Å forkorte alle tidsavbrot eller gripe etter ein brei kill er måten reine stopp blir til øydelagd tilstand ved neste oppstart.

Kople frå gjennom eigaren, og test deretter tre tilfelle

Når forbrukarane er nede, be leiaren som eig tunnelen om å kople frå: systemd-instansen, den aktive NetworkManager-tilkoplinga eller tenesta til leverandøren. Å drepe ein urelatert OpenVPN-prosess fjernar ikkje naudsynt økta som leverte ruta, og ein proksy med omstartspolicy kan gjenopprette ein førespurnad medan du demonterer banen. Koordiner den policyen med den planlagde stoppen før du byrjar.

Test ein normal stopp, ein stopp med ein aktiv førespurnad og ein stopp der tunnelen feilar fyrst. Ein repeterbar sekvens med ein frist slår ei rask nedstenging som fungerer éin gong.