PID-fil til stede, ingen tunnel: kørte OpenVPN nogensinde?

Når starteren nægter at starte OpenVPN, fordi der allerede findes en PID-fil, er den naturlige læsning, at der kører en tunnel et sted. Den læsning er forkert ofte nok til at være værd at kontrollere, før noget slettes. En fil i en runtime-mappe er bogholderi, og bogholderi overlever nedbrud, genstarter og afbrudte nedlukninger, der ikke efterlod nogen proces. To spørgsmål afgør sagen: findes der en levende proces, og tilhører den proces denne instans.

Begynd med tjenesten, ikke filen

Afvisningen kommer normalt fra en starter snarere end fra OpenVPN selv. Den læser en sti, finder noget der og stopper, før der parses en konfiguration. Det første spørgsmål handler derfor om starterens kontrakt, ikke om tunnelen.

Læs den unit eller det script, der udskrev meddelelsen, og noter tre ting: den sti den tjekker, den tjenestetype den erklærer, og om den overhovedet er ansvarlig for at skrive filen. En moderne unit kan bruge simpel eller notify-overvågning og aldrig røre en PID-fil, mens et ældre init-script selv kan oprette en. At kopiere et tjek fra den ene model til den anden giver præcis denne slags afvisning. Find ud af, hvilken model der bruges, før du fortolker noget.

Først da bliver spørgsmålet, om en instans faktisk kører.

Tjek, om den identifikator tilhører din instans

Et tal i en fil beviser, at et tal blev skrevet. Det beviser ikke, at en proces med den identifikator findes nu, og det beviser bestemt ikke, at processen er din, fordi identifikatorer genbruges efter en genstart.

Sammenlign processens starttid med filens tidsstempel, den kørende fil med unitens kommando og tjenestemedlemskabet med unitens navn. Uoverensstemmelse i en af de tre betyder, at du kigger på bogholderi og ikke på en tunnel.

På en vært med containere eller flere navnerum kan en identifikator være meningsfuld i én visning og fraværende i en anden. At du ikke kan se en proces er heller ikke bevis for, at den ikke findes, hvis din konto ikke kan inspicere den. Tjek fra den kontekst, starteren bruger, før du drager konklusioner.

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

Hvad starteren lovede at gøre med filen

PIDFile= fortæller tjenestestyringen, hvor den skal læse hovedprocessens identifikator. Styringen skriver ikke den fil, men den fjerner en overlevende efter nedlukning, og det er præcis derfor, en afbrudt afslutning kan efterlade en fil.

Den ansvarsdeling forklarer to symptomer, som folk rapporterer som fejl. En fil, der aldrig dukker op, betyder, at daemonen eller dens script ikke fik den skrevet, ikke at overvågningen er forkert sat op. En fil, der overlever en stop, betyder, at nedlukningsforløbet aldrig blev færdigt.

Det forklarer også, hvorfor aktuelle retningslinjer foreslår at undgå konventionen, når overvågning kan følge hovedprocessen direkte. De retningslinjer er ikke tilladelse til at ændre en pakket units type, fordi daemonens adfærd i forgrunden, ved fork eller ved notifikation skal matche det, uniten erklærer. Ændr typen uden at ændre daemonen, og du får en unit, der rapporterer fejl, mens tunnelen kører, eller det modsatte. Få parret til at passe, eller lad begge være. systemd-tjenestetreference beskriver ejerskabsdelingen.

Ren nedlukning kontra afbrudt afslutning

En ren stop beder daemonen om at afslutte, venter på den og lader styringen rydde op i sit eget bogholderi. En afbrudt afslutning, en dræbt proces eller en genstart midt i nedlukningen springer dele af den sekvens over, og filen er det, der er tilbage. At finde en efter et nedbrud fortæller dig, at nedlukningen ikke blev færdig, ikke at noget lytter.

Sammenlign filens tidsstempel med den seneste opstart og med unitens seneste stop.

Tjek derefter de levende beviser direkte. En socket bundet til VPN-porten og en tunnelgrænseflade med en adresse er bevis for, at noget kører, på en måde som en tekstfil i en runtime-mappe aldrig er. Hvis begge mangler, kører intet, hvad filen end påstår.

Hold op med at slette filen som vane

At slette den er et legitimt gendannelsesskridt, når du har fastslået, at ingen instans ejer den, og at starteren dokumenterer denne adfærd.

Som permanent vane før start underminerer det det tjek, du arbejder uden om. Hvis forældede filer vender tilbage efter hver ren stop, er skribenten og nedlukningslivscyklussen uenige om, hvem der ejer stien, og den uenighed er den fejl, der er værd at rette.

Behold en uafhængig vej ind til værten, start én instans gennem dens normale styring, og læs det første resultat. Den næste person får en unit, der enten virker eller forklarer sig selv.