PID failas yra, tunelio nėra: ar OpenVPN kada nors veikė?

Kai paleidiklis atsisako paleisti OpenVPN, nes PID failas jau egzistuoja, natūralus skaitymas yra toks, kad kažkur veikia tunelis. Šis skaitymas pakankamai dažnai klaidingas, kad vertėtų jį patikrinti prieš ką nors ištrinant. Failas vykdymo kataloge yra apskaita, o apskaita išgyvena gedimus, perkrovimus ir nutrauktus išjungimus, kurie nepaliko proceso. Atvejį nusprendžia du klausimai: ar yra gyvas procesas ir ar tas procesas priklauso šiai instancijai.

Pradėkite nuo paslaugos, o ne nuo failo

Atsisakymas paprastai ateina iš paleidiklio, o ne iš paties OpenVPN. Jis nuskaito kelią, randa ten ką nors ir sustoja prieš išanalizuodamas konfigūraciją. Taigi pirmasis klausimas yra apie paleidiklio sutartį, o ne apie tunelį.

Perskaitykite unitą arba scenarijų, kuris atspausdino pranešimą, ir atkreipkite dėmesį į tris dalykus: tikrinamą kelią, deklaruojamą paslaugos tipą ir ar jis apskritai atsakingas už failo rašymą. Šiuolaikinis unitas gali naudoti paprastą arba pranešimų priežiūrą ir niekada neliesti PID failo, o senesnis init scenarijus gali pats jį sukurti. Patikros kopijavimas iš vieno modelio į kitą sukuria būtent tokį atsisakymą. Išsiaiškinkite, kuris modelis naudojamas, prieš ką nors interpretuodami.

Tik tada klausimas tampa toks, ar instancija tikrai veikia.

Patikrinkite, ar tas identifikatorius priklauso jūsų instancijai

Skaičius faile įrodo, kad skaičius buvo įrašytas. Jis neįrodo, kad procesas su tuo identifikatoriumi dabar egzistuoja, ir tikrai neįrodo, kad procesas yra jūsų, nes identifikatoriai po perkrovimo naudojami iš naujo.

Palyginkite proceso paleidimo laiką su failo laiko žyma, vykdomąjį failą su unito komanda, o narystę paslaugoje su unito pavadinimu. Neatitikimas bet kuriame iš trijų reiškia, kad žiūrite į apskaitą, o ne į tunelį.

Hoste, kuriame veikia konteineriai ar keli vardų sričių rinkiniai, identifikatorius viename vaizde gali būti prasmingas, o kitame jo gali nebūti. Proceso nematymas taip pat nėra įrodymas, kad jo nėra, jei jūsų paskyra negali jo patikrinti. Tikrinkite iš konteksto, kurį naudoja paleidiklis, prieš darydami išvadas.

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

Ką paleidiklis pažadėjo daryti su failu

PIDFile= paslaugos valdytojui nurodo, iš kur skaityti pagrindinio proceso identifikatorių. Valdytojas to failo nerašo, bet pašalina išlikusį po išjungimo, ir būtent todėl nutrauktas išėjimas gali palikti failą.

Šis atsakomybės padalijimas paaiškina du simptomus, kuriuos žmonės praneša kaip klaidas. Failas, kuris niekada nepasirodo, reiškia, kad demonas ar jo scenarijus nesugebėjo jo įrašyti, o ne kad priežiūra sukonfigūruota neteisingai. Failas, kuris išlieka po sustabdymo, reiškia, kad išjungimo kelias niekada nebuvo baigtas.

Tai taip pat paaiškina, kodėl dabartinės gairės pataria vengti šios konvencijos, kai priežiūra gali tiesiogiai sekti pagrindinį procesą. Šios gairės nėra leidimas keisti supakuoto unito tipą, nes demono veikimas pirmame plane, šakodamasis arba pranešdamas turi atitikti tai, ką unitas deklaruoja. Pakeiskite tipą nekeisdami demono ir gausite unitą, kuris praneša apie gedimą, kol tunelis veikia, arba atvirkščiai. Suderinkite porą arba palikite abu. systemd paslaugos nuoroda aprašo nuosavybės padalijimą.

Švarus išjungimas prieš nutrauktą išėjimą

Švarus sustabdymas paprašo demono išeiti, jo palaukia ir leidžia valdytojui susitvarkyti savo apskaitą. Nutrauktas išėjimas, nužudytas procesas arba perkrovimas išjungimo metu praleidžia dalis tos sekos, ir failas yra tai, kas lieka. Jo radimas po gedimo pasako, kad išjungimas nebuvo baigtas, o ne kad kažkas klausosi.

Palyginkite failo laiko žymą su paskutiniu įkrovimu ir su paskutiniu unito sustabdymu.

Tada tiesiogiai patikrinkite gyvus įrodymus. Prie VPN prievado prijungtas socketas ir tunelio sąsaja su adresu yra įrodymas, kad kažkas veikia, taip, kaip teksto failas vykdymo kataloge niekada nėra. Jei abiejų nėra, niekas neveikia, ką bebūtų teigiama faile.

Nustokite trinti failą iš įpročio

Jį ištrinti yra teisėtas atkūrimo žingsnis, kai nustatėte, kad jokia instancija jo neturi ir kad paleidiklis dokumentuoja šį elgesį.

Kaip nuolatinis įprotis prieš paleidimą, jis panaikina patikrą, kurią bandote apeiti. Jei pasenę failai grįžta po kiekvieno švaraus sustabdymo, rašytojas ir išjungimo gyvavimo ciklas nesutaria, kam priklauso kelias, ir tas nesutarimas yra klaida, kurią verta ištaisyti.

Išlaikykite nepriklausomą kelią į hostą, paleiskite vieną instanciją per įprastą valdytoją ir perskaitykite pirmą rezultatą. Kitas žmogus gauna unitą, kuris arba veikia, arba paaiškina save.