Az OpenVPN elindult, de semmit nem írt ki: először a log-appendet ellenőrizze

OpenVPN-t indít egy héjból egy konfigurációs fájllal, és a terminál minden kimenet nélkül ott marad. Nincs banner, nincs hiba, nincs parancssor-jel. Az ösztön azt mondja, hogy az indítás sikertelen volt, ezért indít még egy példányt, majd még egyet, és a gépen több félkonfigurált példány marad. Mindezek előtt nézze meg a profilban azt az utasítást, amely már máshová irányította a naplót. A csend a konzol tulajdonsága, nem a folyamaté.

A csendnek két nagyon különböző magyarázata van

Az első, hogy a folyamat jól működik, és egy olyan fájlba ír, amelyet nem figyel. A második, hogy azonnal kilépett egy ugyanabban a fájlban rögzített hibával.

Mindkettő üres terminált hagy, és egyetlen kérdés választja el őket: van-e most folyamat, és mi van abban a fájlban, amelybe írnia kellett. Válaszoljon erre, mielőtt újra hozzányúl a konfigurációhoz. Az újraindítás a kimenetért az az út, amelyen két példány elkezd harcolni egyetlen alagúteszközért és ugyanazért a portért, ami olyan hibákat szül, amelyeknek semmi közük az eredeti problémához.

Keresse meg az utasítást, majd keresse meg a folyamatot.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Keresse meg a futó folyamat által használt célhelyet

Azt a profilt olvassa, amellyel a folyamat valóban elindult, ne azt, amelyet szerkesztett. A szolgáltatás által kezelt példány általában más útvonalat tölt be, és más munkakönyvtárral fut, ezért egy relatív fájlnév olyan helyen oldódik fel, ahol nem számított rá.

Egy kifejezett cd utasítás élesebbé teszi ezt a különbséget, mert a relatív útvonal a könyvtárváltással együtt mozog. Ha ezt a konfigurációt örökölte, a fájl olyan helyen lehet, ahol ma senki nem keresné.

Hasonlítsa össze a fájl módosítási idejét azzal a pillanattal, amikor elindította. A múlt heti napló a múlt hétre vonatkozó bizonyíték. Ezután olvassa el a megváltozott fájl utolsó sorait, és tekintse azt, ami ott van, a hiányzó indítási üzenetnek.

log kontra log-append: bizonyíték és törlés

log-append hozzáfűzi mindahhoz, ami már a fájlban van. log írásra nyitja a fájlt és levágja, ezért a kettő közötti váltás törölheti azt a futást, amelyet éppen olvasni készült.

Ha valaki a hibakeresés közben megváltoztatta az utasítást, a korábbi bizonyíték már eltűnt, és a fájl mérete gyanúsan kicsinek fog tűnni. Ezt érdemes tudni, mielőtt két futást összehasonlít, és arra jut, hogy valami megváltozott. Töröljön naplót szándékosan, vagy tartsa meg, de tudja, melyiket tette. A szándékosan eltávolított bizonyítékot könnyebb megindokolni, mint a véletlenül elveszettet.

Egyik lehetőség sem hozza létre a hiányzó szülőkönyvtárakat, és egyik sem ad hozzáférést fájlrendszer-jogosultságokon vagy szolgáltatás-homokozón keresztül. Egy a konfigurációban helyesnek tűnő útvonal továbbra is írhatatlan lehet annak a fióknak, amely alatt a daemon fut, és akkor a daemon meghiúsulhat, mielőtt bármit jelenthetne. Ellenőrizze, hogy létezik-e a könyvtár és ki a tulajdonosa, mielőtt feltételezné, hogy a fájlnév a probléma.

Amikor egy szolgáltatás-burkoló elkapja a kimenetet

A systemd alatt a szabványos kimenet és a hiba a journalba kerül, hacsak egy kifejezett fájlutasítás elsőbbséget nem élvez, és egy szállítói burkoló teljesen máshol kaphatja el őket.

Ezért viselkedik ugyanaz a profil másképp héjból és unitból. Az unit környezete, munkakönyvtára és szabványos folyamai mind különböznek az interaktív héjtól. Egy relatív útvonal feloldódhat az egyik kontextusban, és a másikban sehová nem juthat. Ha a kettő ellentmond, az unit definícióját olvassa, ne a profilt.

Hasonlítsa össze a két indítási elrendezést, ahelyett hogy arra jutna, hogy az egyik hibás. Olvassa el az unit parancssorát és környezetét, majd a journalt ugyanarra az időablakra. Ha a burkoló a kimenetet a saját fájljába irányítja, az a fájl most az ön naplója, és az OpenVPN utasításai irrelevánsak abban, hogy hová mentek az üzenetek.

Csak akkor növelje a részletességet, ha már olvasni tudja

A részletesség növelése a célhely megtalálása előtt csak több szöveget termel egy olyan helyen, amelyet nem néz.

Ha már tudja, hová kerül a kimenet, egy mérsékelt szint megmutatja, hogy a profil elemzése és a kapcsolat megkísérlése folyik. Kettő vagy három elég egy indítási problémához. A magasabb szintek akkor érdemlik ki a helyüket, amikor a hiba a tárgyalás részlete, és a fájlt is gyorsan növelik.

Ezután olvassa el a tényleges hibát. A csendes terminál semmit nem bizonyít arról, hogy az alagút feljött-e, és a fájlban rögzített hiba az, amelyet érdemes javítani.