May file na PID, walang tunnel: tumakbo kaya ang OpenVPN?

Kapag tumanggi ang launcher na simulan ang OpenVPN dahil may file nang PID, ang likas na pagbasa ay may tumatakbong tunnel sa isang lugar. Madalas na mali ang pagbasang iyon kaya sulit itong suriin bago magbura ng kahit ano. Ang file sa runtime directory ay accounting, at ang accounting ay nakakaligtas sa mga pag-crash, pag-reboot at naantalang pagsasara na walang naiwang proseso. Dalawang tanong ang nagpapasya: may buhay bang proseso, at kabilang ba ang prosesong iyon sa instance na ito.

Magsimula sa serbisyo, hindi sa file

Ang pagtanggi ay karaniwang galing sa launcher at hindi sa OpenVPN mismo. Nagbabasa ito ng path, may nahahanap doon at humihinto bago pa suriin ang configuration. Kaya ang unang tanong ay tungkol sa kontrata ng launcher, hindi sa tunnel.

Basahin ang unit o script na nag-print ng mensahe at pansinin ang tatlong bagay: ang path na sinusuri nito, ang uri ng serbisyong idinedeklara nito, at kung responsable ba ito sa pagsulat ng file. Ang modernong unit ay maaaring gumamit ng simpleng o notify na pangangasiwa at hindi kailanman hahawak sa file na PID, samantalang ang lumang init script ay maaaring gumawa mismo ng isa. Ang pagkopya ng pagsusuri mula sa isang modelo patungo sa isa pa ay gumagawa ng ganitong uri ng pagtanggi. Alamin kung aling modelo ang ginagamit bago magbigay-kahulugan sa anuman.

Pagkatapos lang ay nagiging tanong kung talagang tumatakbo ang isang instance.

Suriin kung kabilang sa iyong instance ang identifier na iyon

Ang numero sa file ay nagpapatunay na may naisulat na numero. Hindi nito pinatutunayan na may prosesong may ganoong identifier ngayon, at tiyak na hindi nito pinatutunayan na sa iyo ang proseso, dahil muling ginagamit ang mga identifier pagkatapos ng reboot.

Ihambing ang oras ng pagsisimula ng proseso sa timestamp ng file, ang executable sa command ng unit, at ang pagiging miyembro ng serbisyo sa pangalan ng unit. Ang hindi pagtutugma sa alinman sa tatlo ay nangangahulugang accounting ang tinitingnan mo at hindi tunnel.

Sa host na nagpapatakbo ng mga container o maraming namespace, ang identifier ay maaaring makabuluhan sa isang view at wala sa iba. Ang hindi pagkitang proseso ay hindi rin patunay na wala ito, kung hindi ito masuri ng iyong account. Suriin mula sa kontekstong ginagamit ng launcher bago gumawa ng konklusyon.

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

Ano ang ipinangako ng launcher na gagawin sa file

PIDFile= ay nagsasabi sa service manager kung saan babasahin ang identifier ng pangunahing proseso. Hindi isinusulat ng manager ang file na iyon, ngunit tinatanggal nito ang natira pagkatapos ng shutdown, at iyon mismo ang dahilan kung bakit ang naantalang paglabas ay makakapag-iwan ng file.

Ang paghahati ng responsibilidad na ito ay nagpapaliwanag ng dalawang sintomas na iniuulat ng mga tao bilang bug. Ang file na hindi kailanman lumilitaw ay nangangahulugang nabigo ang daemon o ang script nito na isulat ito, hindi na mali ang configuration ng pangangasiwa. Ang file na nakakaligtas sa paghinto ay nangangahulugang hindi natapos ang landas ng pagsasara.

Ipinapaliwanag din nito kung bakit iminumungkahi ng kasalukuyang mga patnubay na iwasan ang kombensiyon kapag kayang subaybayan ng pangangasiwa ang pangunahing proseso nang direkta. Ang patnubay na iyon ay hindi pahintulot na baguhin ang uri ng naka-package na unit, dahil ang pag-uugali ng daemon sa harapan, sa sanga o sa abiso ay dapat tumugma sa idinedeklara ng unit. Baguhin ang uri nang hindi binabago ang daemon at makakakuha ka ng unit na nag-uulat ng pagkabigo habang tumatakbo ang tunnel, o kabaliktaran. Itugma ang pares, o iwanan ang dalawa. Inilalarawan ng sanggunian ng serbisyong systemd ang paghahating ito ng pagmamay-ari.

Malinis na pagsasara laban sa naantalang paglabas

Ang malinis na paghinto ay humihiling sa daemon na lumabas, hinihintay ito at hinahayaang ayusin ng manager ang sarili nitong accounting. Ang naantalang paglabas, pinatay na proseso o reboot sa gitna ng pagsasara ay lumalaktaw sa mga bahagi ng pagkakasunod-sunod na iyon, at ang file ang natitira. Ang paghahanap nito pagkatapos ng crash ay nagsasabi na hindi natapos ang pagsasara, hindi na may nakikinig.

Ihambing ang timestamp ng file sa huling boot at sa huling paghinto ng unit.

Pagkatapos ay direktang suriin ang mga buhay na ebidensiya. Ang socket na nakatali sa port ng VPN at interface ng tunnel na may address ay patunay na may tumatakbo, sa paraang hindi kailanman nagiging isang text file sa runtime directory. Kung wala ang dalawa, walang tumatakbo, ano man ang sabihin ng file.

Itigil ang pagbura ng file dahil sa ugali

Ang pagbura nito ay lehitimong hakbang sa pagbawi kapag napatunayan mo na walang instance ang nagmamay-ari nito at dokumentado ng launcher ang pag-uugaling ito.

Bilang permanenteng ugali bago magsimula, pinapawalang-bisa nito ang pagsusuring iniiwasan mo. Kung bumabalik ang mga lumang file pagkatapos ng bawat malinis na paghinto, hindi nagkakasundo ang manunulat at ang ikot ng buhay ng pagsasara kung kanino ang landas, at ang hindi pagkakasundong iyon ang bug na sulit ayusin.

Panatilihin ang malayang daan patungo sa host, simulan ang isang instance sa pamamagitan ng normal nitong manager, at basahin ang unang resulta. Ang susunod na tao ay makakakuha ng unit na gumagana o nagpapaliwanag sa sarili nito.