PID-lêer teenwoordig, geen tonnel: Het OpenVPN ooit geloop?

Wanneer die launcher weier om OpenVPN te begin omdat daar reeds 'n PID-lêer bestaan, is die natuurlike lees dat 'n tonnel ergens aktief is. Daardie lees is dikwels genoeg verkeerd om dit te kontroleer voordat enigiets verwyder word. 'n Lêer in 'n runtime-gids is boekhouding, en boekhouding oorleef ineenstortings, herstarts en onderbroke afsluitings wat geen proses agtergelaat het nie. Twee vrae bepaal die saak: is daar 'n lewende proses, en behoort daardie proses aan hierdie instansie?

Begin by die diens, nie by die lêer nie

Die weiering kom gewoonlik van 'n launcher eerder as van OpenVPN self. Dit lees 'n pad, vind iets daar, en stop voordat 'n konfigurasie ontleed word. Die eerste vraag gaan dus oor die launcher se kontrak, nie oor die tonnel nie.

Lees die unit of script wat die boodskap gedruk het en let op drie dinge: die pad wat dit nagaan, die dienstipe wat dit verklaar, en of dit hoegenaamd verantwoordelik is vir die skryf van die lêer. 'n Moderne unit kan eenvoudige of notify-toesig gebruik en nooit aan 'n PID-lêer raak nie, terwyl 'n ouer init-script self een kan skep. Om 'n kontrole van die een model na die ander te kopieer, lewer presies hierdie soort weiering. Vind eers uit watter model in gebruik is voordat jy enigiets interpreteer.

Eers dan word die vraag of 'n instansie werklik loop.

Kontroleer of daardie identifiseerder aan jou instansie behoort

'n Nommer in 'n lêer bewys dat 'n nommer geskryf is. Dit bewys nie dat 'n proses met daardie identifiseerder nou bestaan nie, en dit bewys beslis nie dat die proses joune is nie, want identifiseerders word ná 'n herstart hergebruik.

Vergelyk die proses se begintyd met die lêer se tydstempel, die uitvoerbare lêer met die unit se opdrag, en die dienslidmaatskap met die unit se naam. 'n Wanverhouding in enige van die drie beteken jy kyk na boekhouding eerder as na 'n tonnel.

Op 'n gasheer wat houers of verskeie naamruimtes laat loop, kan 'n identifiseerder in een aansig betekenisvol wees en in 'n ander afwesig. Om nie 'n proses te sien nie is ook nie bewys dat dit nie bestaan nie, as jou rekening dit nie kan inspekteer nie. Kyk vanuit die konteks wat die launcher gebruik voordat jy gevolgtrekkings maak.

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

Wat die launcher belowe het om met die lêer te doen

PIDFile= sê vir die diensbestuurder waar om die hoofproses se identifiseerder te lees. Die bestuurder skryf nie daardie lêer nie, maar dit verwyder wel 'n oorblywende een ná afsluiting, en dit is presies waarom 'n onderbroke uitgang 'n lêer kan agterlaat.

Daardie verdeling van verantwoordelikheid verduidelik twee simptome wat mense as foute rapporteer. 'n Lêer wat nooit verskyn nie, beteken die daemon of sy script het versuim om dit te skryf, nie dat toesig verkeerd opgestel is nie. 'n Lêer wat 'n stop oorleef, beteken die afsluitpad het nooit voltooi nie.

Dit verduidelik ook waarom huidige riglyne voorstel om die konvensie te vermy wanneer toesig die hoofproses direk kan volg. Daardie riglyn is nie toestemming om 'n verpakte unit se tipe te verander nie, want die daemon se foreground-, forking- of kennisgewinggedrag moet ooreenstem met wat die unit verklaar. Verander die tipe sonder om die daemon te verander en jy kry 'n unit wat mislukking rapporteer terwyl die tonnel loop, of die omgekeerde. Pas die paar, of los albei. Die systemd-diensverwysing beskryf die verdeling van eienaarskap.

Skoon afsluiting teenoor onderbroke uitgang

'n Skoon stop vra die daemon om te stop, wag vir hom, en laat die bestuurder sy eie boekhouding opruim. 'n Onderbroke uitgang, 'n gedoodde proses of 'n herstart tydens afsluiting slaan dele van daardie reeks oor, en die lêer is wat oorbly. Om een ná 'n ineenstorting te vind, sê dat die afsluiting nie klaargemaak is nie, nie dat iets luister nie.

Vergelyk die lêer se tydstempel met die laaste selflaai en met die unit se laaste stop.

Kontroleer dan die lewende bewyse direk. 'n Sok wat aan die VPN-poort gebind is en 'n tonnelkoppelvlak met 'n adres is bewys dat iets loop, op 'n manier wat 'n tekslêer in 'n runtime-gids nooit is nie. As albei afwesig is, loop niks, wat die lêer ook al beweer.

Hou op om die lêer as gewoonte te verwyder

Om dit te verwyder is 'n wettige herstelstap sodra jy vasgestel het dat geen instansie dit besit nie en dat die launcher hierdie gedrag dokumenteer.

As 'n permanente gewoonte voor die begin, verydel dit die kontrole waarmee jy besig is om te werk. As verouderde lêers ná elke skoon stop terugkeer, is die skrywer en die afsluitlewensiklus dit oneens oor wie die pad besit, en daardie onenigheid is die fout wat die moeite werd is om reg te maak.

Hou 'n onafhanklike weg in die gasheer oop, begin een instansie deur sy normale bestuurder, en lees die eerste resultaat. Die volgende persoon kry 'n unit wat óf werk óf homself verduidelik.