Skedari PID ekziston, tunel nuk ka: a funksionoi ndonjëherë OpenVPN?

Kur nisësi refuzon të nisë OpenVPN sepse ekziston tashmë një skedar PID, leximi i natyrshëm është se diku po punon një tunel. Ky lexim është i gabuar mjaft shpesh sa ia vlen të kontrollohet para se të fshihet gjë. Një skedar në një drejtori ekzekutimi është kontabilitet, dhe kontabiliteti i mbijeton rrëzimeve, rinisjeve dhe mbylljeve të ndërprera që nuk lanë asnjë proces. Dy pyetje e vendosin çështjen: a ka një proces të gjallë dhe a i përket ai proces këtij instancë.

Filloni me shërbimin, jo me skedarin

Refuzimi zakonisht vjen nga një nisës dhe jo nga vetë OpenVPN. Lexon një shteg, gjen diçka atje dhe ndalon para se të analizohet një konfigurim. Pyetja e parë është pra për kontratën e nisësit, jo për tunelin.

Lexoni njësinë ose skriptin që shtypi mesazhin dhe vini re tre gjëra: shtegun që kontrollon, llojin e shërbimit që deklaron dhe nëse është përgjegjës për shkrimin e skedarit. Një njësi moderne mund të përdorë mbikëqyrje të thjeshtë ose notify dhe të mos prekë kurrë një skedar PID, ndërsa një skript init i vjetër mund të krijojë vetë një të tillë. Kopjimi i një kontrolli nga një model në tjetrin prodhon pikërisht këtë lloj refuzimi. Zbuloni cili model përdoret para se të interpretoni gjë.

Vetëm atëherë pyetja bëhet nëse një instancë po punon vërtet.

Kontrolloni nëse ai identifikues i përket instancës tuaj

Një numër në një skedar provon se u shkrua një numër. Nuk provon se një proces me atë identifikues ekziston tani, dhe sigurisht nuk provon se procesi është i juaji, sepse identifikuesit ripërdoren pas një rinisjeje.

Krahasoni kohën e nisjes së procesit me vulën kohore të skedarit, ekzekutuesin me komandën e njësisë dhe anëtarësinë në shërbim me emrin e njësisë. Një mospërputhje në cilindo nga të tre tregon se po shikoni kontabilitet dhe jo një tunel.

Në një strehues që ekzekuton kontejnerë ose disa hapësira emrash, një identifikues mund të ketë kuptim në një pamje dhe të mungojë në një tjetër. Të mos shohësh një proces nuk është as provë se ai nuk ekziston, nëse llogaria juaj nuk mund ta inspektojë atë. Kontrolloni nga konteksti që përdor nisësi para se të nxirrni përfundime.

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

Çfarë premtoi nisësi të bëjë me skedarin

PIDFile= i thotë menaxherit të shërbimeve nga ta lexojë identifikuesin e procesit kryesor. Menaxheri nuk e shkruan atë skedar, por heq atë që mbijeton pas mbylljes, dhe pikërisht prandaj një dalje e ndërprerë mund të lërë një skedar.

Kjo ndarje e përgjegjësive shpjegon dy simptoma që njerëzit i raportojnë si gabime. Një skedar që nuk shfaqet kurrë do të thotë që demoni ose skripti i tij nuk arriti ta shkruajë, jo se mbikëqyrja është konfiguruar gabimisht. Një skedar që mbijeton një ndalim do të thotë që rruga e mbylljes nuk përfundoi kurrë.

Kjo shpjegon gjithashtu pse udhëzimet aktuale sugjerojnë të shmanget konventa kur mbikëqyrja mund ta ndjekë drejtpërdrejt procesin kryesor. Këto udhëzime nuk janë leje për të ndryshuar llojin e një njësie të paketuar, sepse sjellja e demonit në plan të parë, në degëzim ose në njoftim duhet të përputhet me atë që deklaron njësia. Ndryshoni llojin pa ndryshuar demonin dhe merrni një njësi që raporton dështim ndërsa tuneli punon, ose të kundërtën. Përputhni çiftin, ose lini të dyja. Referenca e shërbimit systemd përshkruan këtë ndarje të pronësisë.

Mbyllje e pastër kundrejt daljes së ndërprerë

Një ndalim i pastër i kërkon demonit të dalë, e pret atë dhe i lejon menaxherit të rregullojë kontabilitetin e vet. Një dalje e ndërprerë, një proces i vrarë ose një rinisje në mes të mbylljes i kapërcejnë pjesë të atij sekuence, dhe skedari është ai që mbetet. Gjetja e njërit pas një rrëzimi ju thotë se mbyllja nuk përfundoi, jo se diçka po dëgjon.

Krahasoni vulën kohore të skedarit me nisjen e fundit dhe me ndalimin e fundit të njësisë.

Pastaj kontrolloni provat e gjalla drejtpërdrejt. Një socket i lidhur me portën VPN dhe një ndërfaqe tuneli me adresë janë provë se diçka po punon, në një mënyrë që një skedar teksti në një drejtori ekzekutimi nuk është kurrë. Nëse të dyja mungojnë, asgjë nuk po punon, çfarëdo që pretendon skedari.

Ndaloni fshirjen e skedarit si zakon

Fshirja e tij është një hap i ligjshëm rikuperimi pasi të keni vërtetuar se asnjë instancë nuk e zotëron dhe se nisësi e dokumenton këtë sjellje.

Si zakon i përhershëm para nisjes, ai e dëmton kontrollin që po shmangni. Nëse skedarët e vjetuar kthehen pas çdo ndalimi të pastër, shkruesi dhe cikli i jetës së mbylljes nuk bien dakord se kujt i përket shtegu, dhe ai mosmarrëveshje është gabimi që ia vlen të rregullohet.

Mbani një rrugë të pavarur në strehues, nisni një instancë përmes menaxherit të saj normal dhe lexoni rezultatin e parë. Personi tjetër merr një njësi që ose punon ose shpjegohet vetë.