Rekkefølgen for nedstenging av VPN- og proksytjenester i Linux

Heng under nedstenging mens en proksy kjører er sjelden en VPN-feil, selv når VPN-en er det siste som vises på skjermen. Applikasjoner bak proksyen venter fortsatt på en bane som er i ferd med å forsvinne, og enheten som eier tunnelen er ennå ikke bedt om å lukke den. Det som ser ut som en treg tjeneste, er vanligvis et rekkefølgeproblem. Rekkefølge løser flere av disse enn enhver endring av tidsavbrudd.

Arbeid utover i omvendt rekkefølge: forbrukerne først, deretter proksyen, og til slutt tunnelen — hver stoppet av komponenten som startet den.

Lag listen over enheter før du stopper noe

Skriv ned applikasjonsenheten, proksyenheten og VPN-eieren som er involvert i en normal kjøring. Legg til enhver resolver eller hjelpekomponent med egen nedstenging, for det er nettopp dem folk glemmer klokken to om natten. Uten den listen velger den første stoppkommandoen du skriver en tilfeldig offer.

Navn er svakt bevis. En brukerproksy, en systemproksy og en annen kontos tunnel kan dele samme navn, men ha helt urelaterte livssykluser.

Fullfør arbeidet, og stopp deretter forbrukeren

En planlagt stopp begynner med applikasjonen: la den fullføre eller avbryte forespørslene sine, og stopp deretter proksyen gjennom tjenesteenheten. Hvis applikasjonen skal fortsette å kjøre etter at tunnelen er borte, ordne det bevisst i stedet for å la den henge på en rute som er i ferd med å forsvinne.

Forespørsler som var underveis under stoppen hører hjemme i journalen, for det er derfra stormen av nye forsøk kommer ved neste oppstart.

ExecStop og ExecStopPost er forskjellige instrumenter

ExecStop= — er den synkrone stoppoperasjonen; ExecStopPost= — er opprydding som kjører selv etter en mislykket oppstart. En stoppkommando som bare sender et signal til en prosess og returnerer, lar systemd gå videre mens forbrukeren fortsatt tømmer. Alt som må skje uansett hører til post-varianten, og alt som må blokkere stoppen hører til den synkrone. Undersøk den effektive enheten og drop-in-filene dens i stedet for å redigere en pakkefil på stedet.

En avhengighetsgraf ordner stoppjobber. Den gjør ikke et asynkront skript synkront, og den tvinger ikke en ekstern applikasjon til å bekrefte dataene sine.

Begrens stoppen og vit hva begrensningen koster

TimeoutStopSec= begrenser både stoppkommandoen og tjenestens egen avslutning, og systemd eskalerer til en tvungen kill når grensen utløper. Velg verdien ut fra applikasjonens faktiske tømmeatferd, og skriv ned hva som kan gå tapt når grensen slår inn. Et tall valgt fordi maskinen bør slås av raskere, er en innstilling for datatap i forkledning.

Når en stopp fortsatt er treg, registrer enheten, barneprosessene, journalintervallet og tidsavbruddsresultatet. Å forkorte alle tidsavbrudd eller gripe etter en bred kill er måten rene stopp blir til ødelagt tilstand ved neste oppstart.

Koble fra gjennom eieren, og test deretter tre tilfeller

Når forbrukerne er nede, be lederen som eier tunnelen om å koble fra: systemd-instansen, den aktive NetworkManager-tilkoblingen eller leverandørens tjeneste. Å drepe en urelatert OpenVPN-prosess fjerner ikke nødvendigvis økten som leverte ruten, og en proksy med omstartspolicy kan gjenopprette en forespørsel mens du demonterer banen. Koordiner den policyen med den planlagte stoppen før du begynner.

Test en normal stopp, en stopp med en aktiv forespørsel og en stopp der tunnelen feiler først. En repeterbar sekvens med en frist slår en rask nedstenging som fungerer én gang.