PID-fájl van, alagút nincs: futott valaha az OpenVPN?

Amikor az indító azért tagadja meg az OpenVPN indítását, mert már létezik egy PID-fájl, a természetes olvasat az, hogy valahol fut egy alagút. Ez az olvasat elég gyakran téves ahhoz, hogy érdemes legyen ellenőrizni, mielőtt bármit törölünk. Egy fájl a futásidejű könyvtárban könyvelés, a könyvelés pedig túléli azokat az összeomlásokat, újraindításokat és megszakított leállásokat, amelyek nem hagytak hátra folyamatot. Két kérdés dönti el az esetet: van-e élő folyamat, és ahhoz a példányhoz tartozik-e.

Kezdje a szolgáltatással, ne a fájllal

A megtagadás általában egy indítótól származik, nem magától az OpenVPN-től. Beolvas egy útvonalat, talál ott valamit, és leáll, mielőtt egy konfigurációt feldolgozna. Az első kérdés tehát az indító szerződéséről szól, nem az alagútról.

Olvassa el az üzenetet kiíró unitot vagy szkriptet, és jegyezzen meg három dolgot: az ellenőrzött útvonalat, a megadott szolgáltatástípust, és hogy egyáltalán felelős-e a fájl írásáért. Egy modern unit használhat egyszerű vagy notify-felügyeletet, és soha nem nyúl PID-fájlhoz, míg egy régebbi init-szkript maga is létrehozhat egyet. Egy ellenőrzés átmásolása az egyik modellből a másikba pontosan ilyen megtagadást eredményez. Derítse ki, melyik modellt használják, mielőtt bármit értelmez.

Csak ezután válik a kérdés azzá, hogy fut-e valóban egy példány.

Ellenőrizze, hogy ez az azonosító a saját példányához tartozik-e

Egy szám a fájlban azt bizonyítja, hogy egy számot leírtak. Nem bizonyítja, hogy most létezik folyamat ezzel az azonosítóval, és természetesen azt sem, hogy a folyamat a magáé, mert az azonosítók újraindítás után újra felhasználhatók.

Hasonlítsa össze a folyamat indulási idejét a fájl időbélyegével, a futtatható fájlt az unit parancsával, a szolgáltatási tagságot pedig az unit nevével. Ha a három közül bármelyik eltér, akkor könyvelést néz, nem alagutat.

Konténereket vagy több névteret futtató gazdagépen egy azonosító az egyik nézetben értelmes lehet, a másikban hiányozhat. Az sem bizonyíték arra, hogy egy folyamat nem létezik, ha a fiókja nem tudja megvizsgálni. A következtetések levonása előtt abból a környezetből ellenőrizzen, amelyet az indító használ.

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

Mit ígért az indító a fájllal kapcsolatban

PIDFile= megmondja a szolgáltatáskezelőnek, honnan olvassa a fő folyamat azonosítóját. A kezelő nem írja ezt a fájlt, de eltávolítja a leállás után megmaradtat, és éppen ezért hagyhat hátra fájlt egy megszakított kilépés.

Ez a felelősségmegosztás magyarázza azt a két tünetet, amelyet az emberek hibaként jelentenek. Az a fájl, amely soha nem jelenik meg, azt jelenti, hogy a daemon vagy a szkriptje nem tudta leírni, nem pedig azt, hogy a felügyelet hibásan van beállítva. Az a fájl, amely túléli a leállítást, azt jelenti, hogy a leállítási útvonal soha nem fejeződött be.

Azt is megmagyarázza, miért javasolják a jelenlegi iránymutatások a konvenció elkerülését, amikor a felügyelet közvetlenül követheti a fő folyamatot. Ezek az iránymutatások nem engedélyt jelentenek egy csomagolt unit típusának megváltoztatására, mert a daemon előtérbeli, elágazó vagy értesítési viselkedésének meg kell felelnie annak, amit az unit deklarál. Változtassa meg a típust a daemon megváltoztatása nélkül, és olyan unitot kap, amely hibát jelent, miközben az alagút fut, vagy fordítva. Párosítsa a kettőt, vagy hagyja mindkettőt. A systemd szolgáltatásreferencia leírja a tulajdon megosztását.

Tiszta leállás szemben a megszakított kilépéssel

A tiszta leállítás arra kéri a daemont, hogy lépjen ki, megvárja, és hagyja, hogy a kezelő rendbe tegye a saját könyvelését. A megszakított kilépés, a megölt folyamat vagy a leállás közbeni újraindítás kihagyja a sorozat egyes részeit, és a fájl az, ami marad. Ha összeomlás után talál egyet, az azt jelenti, hogy a leállás nem fejeződött be, nem pedig azt, hogy valami figyel.

Hasonlítsa össze a fájl időbélyegét az utolsó indítással és az unit utolsó leállításával.

Ezután közvetlenül ellenőrizze az élő bizonyítékokat. A VPN-porthoz kötött socket és egy címmel rendelkező alagút-interfész bizonyítja, hogy valami fut, olyan módon, ahogy egy szöveges fájl a futásidejű könyvtárban soha nem tudja. Ha mindkettő hiányzik, semmi sem fut, bármit is állít a fájl.

Hagyja abba a fájl törlését szokásból

A törlése legitim helyreállítási lépés, miután megállapította, hogy egyetlen példány sem birtokolja, és hogy az indító dokumentálja ezt a viselkedést.

Állandó indítás előtti szokásként aláássa azt az ellenőrzést, amelyet megkerül. Ha az elavult fájlok minden tiszta leállás után visszatérnek, az író és a leállítási életciklus nem ért egyet abban, ki birtokolja az útvonalat, és ez a nézeteltérés a javításra érdemes hiba.

Tartson fenn egy független utat a gazdagéphez, indítson el egy példányt a szokásos kezelőjén keresztül, és olvassa el az első eredményt. A következő ember olyan unitot kap, amely vagy működik, vagy elmagyarázza magát.