OpenVPN wystartował, ale nic nie wypisał: najpierw sprawdź log-append

Uruchamiasz OpenVPN z powłoki z plikiem konfiguracyjnym, a terminal stoi bez żadnego wyjścia. Żadnego banera, żadnego błędu, żadnego znaku zachęty. Instynkt podpowiada, że uruchomienie się nie udało, więc uruchamiasz kolejną kopię, potem następną, i maszyna zostaje z kilkoma na wpół skonfigurowanymi instancjami. Zanim to zrobisz, sprawdź w profilu dyrektywę, która już przekierowała dziennik gdzie indziej. Cisza jest cechą konsoli, a nie procesu.

Cisza ma dwa bardzo różne wyjaśnienia

Pierwsze jest takie, że proces działa poprawnie i pisze do pliku, którego nie obserwujesz. Drugie jest takie, że zakończył się natychmiast z błędem zapisanym w tym samym pliku.

Oba pozostawiają pusty terminal, a jedno pytanie je rozdziela: czy proces teraz istnieje i co jest w pliku, do którego miał pisać. Odpowiedz na to, zanim ponownie dotkniesz konfiguracji. Ponowne uruchamianie po to, by zobaczyć wyjście, to sposób, w jaki dwie instancje zaczynają walczyć o jedno urządzenie tunelu i ten sam port, co daje błędy niemające nic wspólnego z pierwotnym problemem.

Znajdź dyrektywę, a potem znajdź proces.

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

Znajdź miejsce docelowe, którego używa działający proces

Czytaj profil, z którym proces faktycznie został uruchomiony, a nie ten, który edytowałeś. Instancja zarządzana przez usługę zwykle ładuje inną ścieżkę i działa w innym katalogu roboczym, więc względna nazwa pliku zostaje rozwiązana gdzieś, gdzie się jej nie spodziewałeś.

Wyraźna cd dyrektywa wyostrza tę różnicę, bo względna ścieżka przesuwa się wraz ze zmianą katalogu. Jeśli odziedziczyłeś tę konfigurację, plik może leżeć w miejscu, w którym nikt by go teraz nie szukał.

Porównaj czas modyfikacji pliku z chwilą, w której uruchomiłeś. Dziennik z zeszłego tygodnia jest dowodem na zeszły tydzień. Potem przeczytaj ostatnie linie pliku, który się zmienił, i potraktuj to, co tam jest, jako brakujący komunikat startowy.

log kontra log-append: dowody i wymazywanie

log-append dopisuje do tego, co już jest w pliku. log otwiera plik do zapisu i obcina go, więc przełączanie między nimi może usunąć przebieg, który miałeś przeczytać.

Jeśli ktoś zmienił dyrektywę podczas debugowania, poprzedni dowód już zniknął, a rozmiar pliku będzie podejrzanie mały. Warto o tym wiedzieć, zanim porównasz dwa przebiegi i wyciągniesz wniosek, że coś się zmieniło. Usuń dziennik celowo albo go zachowaj, ale wiedz, co zrobiłeś. Dowody usunięte świadomie łatwiej zrozumieć niż te utracone przypadkiem.

Żadna z opcji nie tworzy brakujących katalogów nadrzędnych ani nie daje dostępu przez uprawnienia systemu plików lub piaskownicę usługi. Ścieżka, która w konfiguracji wygląda poprawnie, nadal może być niezapisywalna dla konta, na którym działa demon, a wtedy demon może zawieść, zanim cokolwiek zgłosi. Sprawdź, czy katalog istnieje i kto jest jego właścicielem, zanim uznasz, że problemem jest nazwa pliku.

Gdy nakładka usługi przechwytuje wyjście

W systemd standardowe wyjście i błędy trafiają do dziennika systemowego, chyba że wyraźna dyrektywa plikowa ma pierwszeństwo, a nakładka dostawcy może je przechwycić zupełnie gdzie indziej.

Dlatego ten sam profil zachowuje się inaczej z powłoki i z jednostki. Środowisko jednostki, jej katalog roboczy i standardowe strumienie różnią się od twojej interaktywnej powłoki. Względna ścieżka może się rozwiązać w jednym kontekście, a w drugim nigdzie nie trafić. Czytaj definicję jednostki, gdy oba się nie zgadzają, a nie profil.

Porównaj oba sposoby uruchamiania, zamiast uznawać, że jeden z nich jest zepsuty. Przeczytaj wiersz poleceń jednostki i jej środowisko, a potem dziennik z tego samego przedziału czasu. Jeśli nakładka przekierowuje wyjście do własnego pliku, ten plik jest teraz twoim dziennikiem, a dyrektywy OpenVPN nie mają znaczenia dla tego, gdzie trafiły komunikaty.

Zwiększ poziom szczegółowości dopiero wtedy, gdy możesz go odczytać

Zwiększanie szczegółowości przed znalezieniem miejsca docelowego daje tylko więcej tekstu w miejscu, na które nie patrzysz.

Gdy wiesz, gdzie trafia wyjście, umiarkowany poziom pokazuje parsowanie profilu i próbę połączenia. Dwa lub trzy wystarczą przy problemie ze startem. Wyższe poziomy zasługują na swoje miejsce, gdy awaria jest szczegółem negocjacji, a dodatkowo szybko powiększają plik.

Potem przeczytaj rzeczywisty błąd. Cichy terminal niczego nie dowodzi w kwestii tego, czy tunel wstał, a błąd zapisany w pliku jest tym, który warto naprawić.