PID-fil finnes, ingen tunnel: kjørte OpenVPN noen gang?

Når oppstarteren nekter å starte OpenVPN fordi det allerede finnes en PID-fil, er den naturlige lesningen at en tunnel kjører et sted. Den lesningen er feil ofte nok til at det er verdt å sjekke før noe slettes. En fil i en kjøretidskatalog er regnskap, og regnskap overlever krasj, omstarter og avbrutte nedstenginger som ikke etterlot noen prosess. To spørsmål avgjør saken: finnes det en levende prosess, og tilhører den prosessen denne instansen.

Begynn med tjenesten, ikke filen

Avvisningen kommer vanligvis fra en oppstarter og ikke fra OpenVPN selv. Den leser en sti, finner noe der og stopper før en konfigurasjon blir tolket. Det første spørsmålet handler derfor om oppstarterens kontrakt, ikke om tunnelen.

Les enheten eller skriptet som skrev ut meldingen, og legg merke til tre ting: stien den sjekker, tjenestetypen den erklærer, og om den i det hele tatt er ansvarlig for å skrive filen. En moderne enhet kan bruke enkel eller notify-overvåking og aldri røre en PID-fil, mens et eldre init-skript selv kan opprette en. Å kopiere en sjekk fra én modell til den andre gir nøyaktig denne typen avvisning. Finn ut hvilken modell som brukes før du tolker noe.

Først da blir spørsmålet om en instans faktisk kjører.

Sjekk om den identifikatoren tilhører din instans

Et tall i en fil beviser at et tall ble skrevet. Det beviser ikke at en prosess med den identifikatoren finnes nå, og det beviser slett ikke at prosessen er din, fordi identifikatorer brukes på nytt etter en omstart.

Sammenlign prosessens starttid med filens tidsstempel, den kjørbare filen med enhetens kommando og tjenestemedlemskapet med enhetens navn. Uoverensstemmelse i en av de tre betyr at du ser på regnskap og ikke på en tunnel.

På en vert som kjører containere eller flere navnerom, kan en identifikator være meningsfull i én visning og mangle i en annen. Å ikke se en prosess er heller ikke bevis for at den ikke finnes, hvis kontoen din ikke kan inspisere den. Sjekk fra konteksten oppstarteren bruker før du trekker konklusjoner.

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

Hva oppstarteren lovet å gjøre med filen

PIDFile= forteller tjenestebehandleren hvor den skal lese identifikatoren til hovedprosessen. Behandleren skriver ikke den filen, men den fjerner en overlevende etter nedstenging, og det er nettopp derfor en avbrutt avslutning kan etterlate en fil.

Denne ansvarsdelingen forklarer to symptomer folk rapporterer som feil. En fil som aldri dukker opp, betyr at daemonen eller skriptet dens ikke fikk skrevet den, ikke at overvåkingen er feil konfigurert. En fil som overlever en stopp, betyr at nedstengingsløpet aldri ble fullført.

Det forklarer også hvorfor gjeldende retningslinjer anbefaler å unngå konvensjonen når overvåking kan følge hovedprosessen direkte. De retningslinjene er ikke tillatelse til å endre typen til en pakket enhet, fordi daemonens oppførsel i forgrunnen, ved forgrening eller ved varsling må samsvare med det enheten erklærer. Endre typen uten å endre daemonen, og du får en enhet som rapporterer feil mens tunnelen kjører, eller det motsatte. Få paret til å stemme, eller la begge være. systemd-tjenestetreferansen beskriver eierskapsdelingen.

Ren nedstenging kontra avbrutt avslutning

En ren stopp ber daemonen avslutte, venter på den og lar behandleren rydde opp i sitt eget regnskap. En avbrutt avslutning, en drept prosess eller en omstart midt i nedstengingen hopper over deler av den sekvensen, og filen er det som blir igjen. Å finne en etter et krasj forteller deg at nedstengingen ikke ble fullført, ikke at noe lytter.

Sammenlign filens tidsstempel med forrige oppstart og med enhetens siste stopp.

Sjekk deretter de levende bevisene direkte. En socket bundet til VPN-porten og et tunnelgrensesnitt med en adresse er bevis for at noe kjører, på en måte en tekstfil i en kjøretidskatalog aldri er. Hvis begge mangler, kjører ingenting, uansett hva filen påstår.

Slutt å slette filen av vane

Å slette den er et legitimt gjenopprettingstrinn når du har fastslått at ingen instans eier den, og at oppstarteren dokumenterer denne oppførselen.

Som permanent vane før oppstart undergraver det sjekken du omgår. Hvis utdaterte filer kommer tilbake etter hver ren stopp, er skribenten og nedstengingslivssyklusen uenige om hvem som eier stien, og den uenigheten er feilen som er verdt å rette.

Hold en uavhengig vei inn til verten, start én instans gjennom dens normale behandler, og les det første resultatet. Den neste personen får en enhet som enten virker eller forklarer seg selv.