PID-fil finns, ingen tunnel: körde OpenVPN någonsin?

När startaren vägrar starta OpenVPN eftersom det redan finns en PID-fil, är den naturliga läsningen att en tunnel kör någonstans. Den läsningen är fel tillräckligt ofta för att vara värd en kontroll innan något raderas. En fil i en runtime-katalog är bokföring, och bokföring överlever krascher, omstarter och avbrutna avstängningar som inte lämnade någon process. Två frågor avgör saken: finns det en levande process, och tillhör den processen den här instansen.

Börja med tjänsten, inte filen

Avslaget kommer vanligtvis från en startare och inte från OpenVPN självt. Den läser en sökväg, hittar något där och stannar innan en konfiguration tolkas. Den första frågan handlar därför om startarens kontrakt, inte om tunneln.

Läs enheten eller skriptet som skrev ut meddelandet och notera tre saker: sökvägen den kontrollerar, tjänstetypen den deklarerar och om den alls ansvarar för att skriva filen. En modern enhet kan använda enkel eller notify-övervakning och aldrig röra en PID-fil, medan ett äldre init-skript självt kan skapa en. Att kopiera en kontroll från den ena modellen till den andra ger precis den här sortens avslag. Ta reda på vilken modell som används innan du tolkar något.

Först då blir frågan om en instans faktiskt kör.

Kontrollera om den identifieraren tillhör din instans

En siffra i en fil bevisar att en siffra skrevs. Det bevisar inte att en process med den identifieraren finns nu, och det bevisar absolut inte att processen är din, eftersom identifierare återanvänds efter en omstart.

Jämför processens starttid med filens tidsstämpel, den körbara filen med enhetens kommando och tjänstemedlemskapet med enhetens namn. En avvikelse i någon av de tre betyder att du tittar på bokföring och inte på en tunnel.

På en värd som kör containrar eller flera namnutrymmen kan en identifierare vara meningsfull i en vy och saknas i en annan. Att inte se en process är inte heller bevis för att den inte finns, om ditt konto inte kan inspektera den. Kontrollera från det sammanhang som startaren använder innan du drar slutsatser.

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

Vad startaren lovade att göra med filen

PIDFile= talar om för tjänstehanteraren var den ska läsa huvudprocessens identifierare. Hanteraren skriver inte den filen, men den tar bort en överlevande efter avstängning, och det är just därför ett avbrutet avslut kan lämna en fil.

Den ansvarsfördelningen förklarar två symtom som folk rapporterar som fel. En fil som aldrig dyker upp betyder att daemonen eller dess skript inte fick den skriven, inte att övervakningen är felkonfigurerad. En fil som överlever ett stopp betyder att avstängningsvägen aldrig slutfördes.

Det förklarar också varför nuvarande riktlinjer föreslår att man undviker konventionen när övervakning kan följa huvudprocessen direkt. De riktlinjerna är inte tillstånd att ändra en paketerad enhets typ, eftersom daemonens beteende i förgrunden, vid förgrening eller vid avisering måste matcha det enheten deklarerar. Ändra typen utan att ändra daemonen, och du får en enhet som rapporterar fel medan tunneln kör, eller det motsatta. Få paret att stämma, eller låt båda vara. systemd-tjänstreferensen beskriver ägarfördelningen.

Ren avstängning kontra avbrutet avslut

Ett rent stopp ber daemonen avsluta, väntar på den och låter hanteraren städa upp sin egen bokföring. Ett avbrutet avslut, en dödad process eller en omstart mitt i avstängningen hoppar över delar av den sekvensen, och filen är det som blir kvar. Att hitta en efter en krasch säger att avstängningen inte slutfördes, inte att något lyssnar.

Jämför filens tidsstämpel med den senaste uppstarten och med enhetens senaste stopp.

Kontrollera sedan de levande bevisen direkt. En socket bunden till VPN-porten och ett tunnelgränssnitt med en adress är bevis för att något kör, på ett sätt som en textfil i en runtime-katalog aldrig är. Saknas båda kör ingenting, vad filen än påstår.

Sluta radera filen av vana

Att radera den är ett legitimt återställningssteg när du har fastställt att ingen instans äger den och att startaren dokumenterar detta beteende.

Som permanent vana före start undergräver det kontrollen du kringgår. Om inaktuella filer återkommer efter varje rent stopp, är skribenten och avstängningens livscykel oense om vem som äger sökvägen, och den oenigheten är felet som är värt att rätta.

Håll en oberoende väg in till värden, starta en instans via dess normala hanterare och läs det första resultatet. Nästa person får en enhet som antingen fungerar eller förklarar sig.