PID-fil finst, ingen tunnel: køyrde OpenVPN nokon gong?

Når oppstartaren nektar å starte OpenVPN fordi det allereie finst ei PID-fil, er den naturlege lesinga at ein tunnel køyrer ein stad. Den lesinga er feil ofte nok til at det er verdt å sjekke før noko slettast. Ei fil i ein køyretidskatalog er rekneskap, og rekneskap overlever krasj, omstart og avbrotne nedstengingar som ikkje etterlet nokon prosess. To spørsmål avgjer saka: finst det ein levande prosess, og høyrer den prosessen til denne instansen.

Byrja med tenesta, ikkje fila

Avvisinga kjem vanlegvis frå ein oppstartar og ikkje frå OpenVPN sjølv. Han les ein sti, finn noko der og stoppar før ein konfigurasjon blir tolka. Det første spørsmålet handlar derfor om kontrakten til oppstartaren, ikkje om tunnelen.

Les eininga eller skriptet som skreiv ut meldinga, og legg merke til tre ting: stien ho sjekkar, tenestetypen ho erklærer, og om ho i det heile er ansvarleg for å skrive fila. Ei moderne eining kan bruke enkel eller notify-overvaking og aldri røre ei PID-fil, medan eit eldre init-skript sjølv kan lage ei. Å kopiere ein sjekk frå éin modell til den andre gir nøyaktig denne typen avvising. Finn ut kva modell som blir brukt før du tolkar noko.

Først då blir spørsmålet om ein instans faktisk køyrer.

Sjekk om den identifikatoren høyrer til din instans

Eit tal i ei fil beviser at eit tal vart skrive. Det beviser ikkje at ein prosess med den identifikatoren finst no, og det beviser slett ikkje at prosessen er din, fordi identifikatorar blir brukte på nytt etter ein omstart.

Samanlikn starttida til prosessen med tidsstempelet til fila, den køyrbare fila med kommandoen til eininga og tenestemedlemskapet med namnet på eininga. Uoverenskomst i ein av dei tre betyr at du ser på rekneskap og ikkje på ein tunnel.

På ein vert som køyrer containerar eller fleire namnerom, kan ein identifikator vere meiningsfull i éin vising og mangle i ei anna. Å ikkje sjå ein prosess er heller ikkje prov for at han ikkje finst, dersom kontoen din ikkje kan inspisere han. Sjekk frå konteksten oppstartaren brukar før du dreg konklusjonar.

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

Kva oppstartaren lova å gjere med fila

PIDFile= fortel tenestebehandsamaren kvar han skal lese identifikatoren til hovudprosessen. Behandsamaren skriv ikkje den fila, men han fjernar ei overlevande etter nedstenging, og det er nettopp derfor ein avbroten avslutting kan etterlate ei fil.

Denne ansvarsdelinga forklarer to symptom folk rapporterer som feil. Ei fil som aldri dukkar opp, betyr at daemonen eller skriptet hans ikkje fekk skrive ho, ikkje at overvakinga er feil konfigurert. Ei fil som overlever ein stopp, betyr at nedstengingsløpet aldri vart fullført.

Det forklarer òg kvifor gjeldande retningslinjer tilrår å unngå konvensjonen når overvaking kan følgje hovudprosessen direkte. Dei retningslinjene er ikkje løyve til å endre typen til ei pakka eining, fordi åtferda til daemonen i forgrunnen, ved forgreining eller ved varsling må samsvare med det eininga erklærer. Endre typen utan å endre daemonen, og du får ei eining som rapporterer feil medan tunnelen køyrer, eller det motsette. Få paret til å stemme, eller la begge vere. systemd-tenestetilvisinga skildrar eigarskapsdelinga.

Rein nedstenging kontra avbroten avslutting

Ein rein stopp ber daemonen avslutte, ventar på han og lèt handsamaren rydde opp i sitt eige rekneskap. Ei avbroten avslutting, ein drepen prosess eller ein omstart midt i nedstenginga hoppar over delar av den sekvensen, og fila er det som blir att. Å finne ei etter eit krasj fortel deg at nedstenginga ikkje vart fullført, ikkje at noko lyttar.

Samanlikn tidsstempelet til fila med førre oppstart og med siste stopp på eininga.

Sjekk deretter dei levande prova direkte. Ein socket bunden til VPN-porten og eit tunnelgrensesnitt med ei adresse er prov for at noko køyrer, på ein måte ei tekstfil i ein køyretidskatalog aldri er. Viss begge manglar, køyrer ingenting, uansett kva fila påstår.

Slutt å slette fila av vane

Å slette ho er eit legitimt gjenopprettingstiltak når du har fastslått at ingen instans eig ho, og at oppstartaren dokumenterer denne åtferda.

Som permanent vane før oppstart undergrev det sjekken du går utanom. Viss utdaterte filer kjem tilbake etter kvar rein stopp, er skribenten og nedstengingslivssyklusen usamde om kven som eig stien, og den usemja er feilen som er verdt å rette.

Hald ein uavhengig veg inn til verten, start éin instans gjennom den normale handsamaren hans, og les det første resultatet. Den neste personen får ei eining som anten verkar eller forklarer seg sjølv.