OpenVPN se spustil, ale nic nevytiskl: nejprve zkontrolujte log-append

Spouštíte OpenVPN ze shellu s konfiguračním souborem a terminál zůstává bez jakéhokoli výstupu. Žádný banner, žádná chyba, žádná výzva. Instinkt říká, že spuštění selhalo, takže spustíte další kopii, pak další, a na stroji skončí několik napůl nakonfigurovaných instancí. Ještě než to uděláte, zkontrolujte v profilu direktivu, která už přesměrovala log jinam. Ticho je vlastnost konzole, ne procesu.

Ticho má dvě velmi odlišná vysvětlení

První je, že proces běží v pořádku a zapisuje do souboru, který nesledujete. Druhé je, že okamžitě skončil s chybou zaznamenanou v témže souboru.

Obě zanechávají prázdný terminál a jedna otázka je odděluje: existuje teď proces a co je v souboru, do kterého měl zapisovat. Odpovězte na to, než se znovu dotknete konfigurace. Restartování kvůli výstupu je způsob, jak spolu dvě instance začnou bojovat o jedno tunelové zařízení a stejný port, což vytváří chyby, které s původním problémem nemají nic společného.

Najděte direktivu, pak najděte proces.

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

Najděte cíl, který používá běžící proces

Čtěte profil, se kterým byl proces skutečně spuštěn, ne ten, který jste upravili. Instance spravovaná službou obvykle načítá jinou cestu a běží v jiném pracovním adresáři, takže relativní název souboru se vyřeší někde, kde jste to nečekali.

Explicitní direktiva cd tuto odlišnost zostřuje, protože relativní cesta se posouvá se změnou adresáře. Pokud jste tuto konfiguraci zdědili, soubor může ležet na místě, kde by ho dnes nikdo nehledal.

Porovnejte čas změny souboru s okamžikem spuštění. Log z minulého týdne je důkaz o minulém týdnu. Potom přečtěte poslední řádky souboru, který se změnil, a považujte to, co tam je, za spouštěcí zprávu, kterou jste postrádali.

log versus log-append: důkaz a vymazání

log-append přidává k tomu, co už v souboru je. log otevírá soubor pro zápis a zkracuje ho, takže přepínání mezi oběma může vymazat běh, který jste se chystali přečíst.

Pokud někdo direktivu během ladění změnil, předchozí důkaz už zmizel a velikost souboru bude vypadat podezřele malá. To je dobré vědět, než porovnáte dva běhy a usoudíte, že se něco změnilo. Smažte log záměrně, nebo ho ponechejte, ale vězte, které z toho jste udělali. Důkaz, který jste odstranili úmyslně, se snáz vysvětluje než důkaz, který jste ztratili náhodou.

Ani jedna z možností nevytváří chybějící nadřazené adresáře a ani jedna neposkytuje přístup přes oprávnění souborového systému nebo servisní sandbox. Cesta, která v konfiguraci vypadá správně, může být pro účet, pod kterým démon běží, stále nezapisovatelná, a pak démon může selhat dřív, než cokoli oznámí. Zkontrolujte, zda adresář existuje a kdo je jeho vlastníkem, než budete předpokládat, že problém je v názvu souboru.

Když obal služby zachytí výstup

Pod systemd jdou standardní výstup a chyba do journalu, pokud nemá přednost explicitní direktiva souboru, a obal od dodavatele je může zachytit úplně jinde.

Proto se stejný profil chová jinak ze shellu a z unitu. Prostředí unitu, jeho pracovní adresář i jeho standardní proudy se liší od vašeho interaktivního shellu. Relativní cesta se může vyřešit v jednom kontextu a v druhém nikam nedojít. Když se oba rozcházejí, čtěte definici unitu, ne profil.

Porovnejte obě uspořádání spuštění, místo abyste usoudili, že jedno z nich je rozbité. Přečtěte příkazový řádek unitu a jeho prostředí, pak přečtěte journal pro stejné časové okno. Pokud obal přesměrovává výstup do vlastního souboru, tím souborem je teď váš log a direktivy OpenVPN nemají vliv na to, kam zprávy šly.

Podrobnost zvyšte až poté, co ji dokážete číst

Zvyšování podrobnosti před nalezením cíle jen vytváří více textu na místě, které nesledujete.

Jakmile víte, kam výstup dopadá, mírná úroveň ukazuje, že se profil parsuje a že se pokouší o spojení. Dvě nebo tři stačí na problém se spuštěním. Vyšší úrovně si své místo zaslouží, když je porucha detail jednání, a také způsobují rychlý růst souboru.

Potom přečtěte skutečnou chybu. Tichý terminál nic nedokazuje o tom, zda tunel naskočil, a porucha zaznamenaná v souboru je ta, kterou stojí za to opravit.