Lukning af Linux VPN- og proxytjenester i den rigtige rækkefølge

Nedlukninger, der hænger, mens en proxy kører, er sjældent en VPN-fejl, selv når VPN er det sidste, der ses på skærmen. Applikationer bag proxyen venter stadig på en sti, der er ved at forsvinde, og den enhed, der ejer tunnelen, er endnu ikke blevet bedt om at lukke den. Det, der ligner en langsom tjeneste, er som regel et ordensproblem. Rækkefølgen løser flere af disse end nogen ændring af tidsgrænsen.

Arbejd udefra i omvendt rækkefølge: forbrugerne først, derefter proxyen, derefter tunnelen, og hver af dem stoppes af den komponent, der startede den.

List enhederne, før du stopper noget

Skriv applikationsenheden, proxyenheden og VPN-ejeren ned, som indgår i en normal kørsel. Tilføj enhver resolver eller hjælper med sin egen nedtagning, for det er dem, folk glemmer klokken to om natten. Uden den liste vælger den første stopkommando, du skriver, et offer tilfældigt.

Navne er svage beviser. En brugerproxy, en systemproxy og en anden kontos tunnel kan dele navn, mens deres livscyklusser er helt uden forbindelse.

Færdiggør arbejdet, og stop så forbrugeren

Et planlagt stop begynder med applikationen: lad den færdiggøre eller annullere sine anmodninger, og stop derefter proxyen gennem dens tjenesteenhed. Hvis applikationen skal fortsætte med at køre, efter tunnelen forsvinder, så arrangér det bevidst i stedet for at lade den hænge på en rute, der er ved at forsvinde.

Anmodninger, der var undervejs under stoppet, hører i registreringen, for det er derfra stormen af genforsøg kommer ved næste opstart.

ExecStop og ExecStopPost er forskellige instrumenter

ExecStop= er den synkrone stopoperation; ExecStopPost= er oprydning, der kører selv efter en mislykket opstart. En stopkommando, der blot sender et signal til en proces og vender tilbage, lader systemd gå videre, mens forbrugeren stadig skyller ud. Alt, der skal ske uanset hvad, hører i eftervarianten, og alt, der skal blokere stoppet, hører i den synkrone. Undersøg den effektive enhed og dens drop-ins i stedet for at redigere en pakkefil på stedet.

En afhængighedsgraf ordner stopjobs. Den gør ikke et asynkront script synkront, og den får heller ikke en fjern applikation til at gemme sine data.

Afgræns stoppet, og vid hvad grænsen koster

TimeoutStopSec= begrænser både stopkommandoen og tjenestens egen afslutning, og systemd eskalerer til et tvunget kill, når grænsen udløber. Vælg værdien ud fra applikationens faktiske udskylningsadfærd, og skriv ned, hvad der kan gå tabt, når den rammes. Et tal valgt, fordi maskinen skal slukke hurtigere, er en datatabstilstand i forklædning.

Når et stop stadig er langsomt, så registrer enheden, dens barneprocesser, journalintervallet og tidsgrænseresultatet. At forkorte hver tidsgrænse eller gribe efter et bredt kill er måden, hvorpå rene nedlukninger bliver til korrupt tilstand ved næste opstart.

Afbryd gennem ejeren, og test så tre tilfælde

Når forbrugerne er nede, så bed den manager, der ejer tunnelen, om at afbryde: systemd-instansen, NetworkManager-forbindelsen eller leverandørens tjeneste. At dræbe en urelateret OpenVPN-proces fjerner ikke nødvendigvis den session, der leverede ruten, og en proxy med genstartsregel kan genskabe en anmodning, mens du skiller stien ad. Koordinér den regel med det planlagte stop, før du begynder.

Test et normalt stop, et stop med en aktiv anmodning og et stop, hvor tunnelen fejler først. En gentagelig sekvens med en deadline slår en hurtig nedlukning, der virker én gang.