Ordningen för att stänga av VPN- och proxytjänster i Linux

Hängningar vid avstängning medan en proxy körs är sällan en VPN-bugg, även när VPN:en är det sista som syns på skärmen. Program bakom proxyn väntar fortfarande på en väg som är på väg att försvinna, och den enhet som äger tunneln har ännu inte blivit ombedd att stänga den. Det som ser ut som en långsam tjänst är oftast ett ordningsproblem. Ordningsföljden löser fler av dessa än någon timeoutändring.

Arbeta utåt i omvänd ordning: först konsumenterna, sedan proxyn och till sist tunneln — var och en stoppad av komponenten som startade den.

Gör listan över enheterna innan du stoppar något

Skriv ned programenheten, proxyenheten och VPN-ägaren som ingår i en normal körning. Lägg till varje resolver eller hjälpkomponent med egen nedstängning, för det är just dem folk glömmer klockan två på natten. Utan den listan väljer det första stoppkommando du skriver ett offer slumpmässigt.

Namn är svagt bevis. En användarproxy, en systemproxy och ett annat kontos tunnel kan dela samma namn men ha helt orelaterade livscykler.

Gör klart arbetet och stoppa sedan konsumenten

En planerad avstängning börjar med programmet: låt det slutföra eller avbryta sina förfrågningar och stoppa sedan proxyn via dess serviceenhet. Om programmet ska fortsätta köra efter att tunneln försvinner, ordna det medvetet i stället för att lämna det kopplat till en väg som är på väg att försvinna.

Förfrågningar som var under vägs under avstängningen hör hemma i journalen, för det är därifrån stormen av nya försök kommer vid nästa start.

ExecStop och ExecStopPost är olika instrument

ExecStop= — är den synkrona stoppoperationen; ExecStopPost= — är städning som körs även efter en misslyckad start. Ett stoppkommando som bara skickar en signal till en process och återvänder låter systemd gå vidare medan konsumenten fortfarande spolar. Allt som måste hända oavsett hör till post-varianten, och allt som måste blockera stoppen hör till den synkrona. Granska den effektiva enheten och dess drop-in-filer i stället för att redigera en paketfil på plats.

En beroendegraf ordnar stoppjobb. Den gör inte ett asynkront skript synkront och tvingar inte ett fjärrprogram att bekräfta sina data.

Begränsa stoppen och vet vad begränsningen kostar

TimeoutStopSec= begränsar både stoppkommandot och tjänstens egen avslutning, och systemd eskalerar till en framtvingad kill när gränsen löper ut. Välj värdet utifrån programmets verkliga spolbeteende och skriv ned vad som kan gå förlorat när gränsen slår till. En siffra som valts för att maskinen ska stängas av snabbare är en inställning för dataförlust i förklädnad.

När en avstängning fortfarande är långsam, fånga enheten, dess barnprocesser, journalintervallet och timeoutresultatet. Att korta alla timeouter eller gripa efter en bred kill är hur rena avstängningar blir till korrupt tillstånd vid nästa uppstart.

Koppla från via ägaren och testa sedan tre fall

När konsumenterna är nere, be hanteraren som äger tunneln att koppla från: systemd-instansen, NetworkManagers aktiva anslutning eller leverantörens tjänst. Att döda en orelaterad OpenVPN-process tar inte nödvändigtvis bort sessionen som gav vägen, och en proxy med omstartsprincip kan återskapa en förfrågan medan du monterar ned vägen. Samordna den principen med den planerade avstängningen innan du börjar.

Testa en normal avstängning, en avstängning med en aktiv förfrågan och en avstängning där tunneln fallerar först. En repeterbar sekvens med en deadline slår en snabb nedstängning som fungerar en gång.