Plik PID jest, tunelu nie ma: czy OpenVPN kiedykolwiek działał?

Gdy program startowy odmawia uruchomienia OpenVPN, bo plik PID już istnieje, naturalnym odczytem jest to, że gdzieś działa tunel. Ten odczyt jest wystarczająco często błędny, by warto było go sprawdzić, zanim cokolwiek zostanie usunięte. Plik w katalogu czasu działania to księgowość, a księgowość przeżywa awarie, restarty i przerwane wyłączenia, które nie pozostawiły procesu. Sprawę rozstrzygają dwa pytania: czy istnieje żywy proces i czy ten proces należy do tej instancji.

Zacznij od usługi, nie od pliku

Odmowa zwykle pochodzi od programu startowego, a nie od samego OpenVPN. Odczytuje ścieżkę, znajduje tam coś i zatrzymuje się, zanim konfiguracja zostanie przeanalizowana. Pierwsze pytanie dotyczy więc umowy programu startowego, a nie tunelu.

Przeczytaj jednostkę lub skrypt, który wypisał komunikat, i zwróć uwagę na trzy rzeczy: sprawdzaną ścieżkę, deklarowany typ usługi i to, czy w ogóle odpowiada za zapis pliku. Nowoczesna jednostka może używać prostego nadzoru lub nadzoru powiadomień i nigdy nie dotykać pliku PID, podczas gdy starszy skrypt init może sam go utworzyć. Skopiowanie sprawdzenia z jednego modelu do drugiego daje dokładnie taką odmowę. Ustal, który model jest używany, zanim cokolwiek zinterpretujesz.

Dopiero wtedy pytanie staje się tym, czy instancja naprawdę działa.

Sprawdź, czy ten identyfikator należy do twojej instancji

Liczba w pliku dowodzi, że liczba została zapisana. Nie dowodzi, że proces o tym identyfikatorze istnieje teraz, i z pewnością nie dowodzi, że proces jest twój, ponieważ identyfikatory są używane ponownie po restarcie.

Porównaj czas uruchomienia procesu ze znacznikiem czasu pliku, plik wykonywalny z poleceniem jednostki, a przynależność do usługi z nazwą jednostki. Niezgodność w którymkolwiek z trzech oznacza, że patrzysz na księgowość, a nie na tunel.

Na hoście uruchamiającym kontenery lub wiele przestrzeni nazw identyfikator może mieć znaczenie w jednym widoku, a w innym go brakować. Niewidzenie procesu też nie jest dowodem, że go nie ma, jeśli twoje konto nie może go sprawdzić. Sprawdź z kontekstu, którego używa program startowy, zanim wyciągniesz wnioski.

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

Co program startowy obiecał zrobić z plikiem

PIDFile= mówi menedżerowi usług, skąd odczytać identyfikator procesu głównego. Menedżer nie zapisuje tego pliku, ale usuwa pozostały po wyłączeniu, i właśnie dlatego przerwane wyjście może pozostawić plik.

Ten podział odpowiedzialności wyjaśnia dwa objawy zgłaszane jako błędy. Plik, który nigdy się nie pojawia, oznacza, że demon lub jego skrypt nie zdołał go zapisać, a nie że nadzór jest źle skonfigurowany. Plik, który przetrwa zatrzymanie, oznacza, że ścieżka wyłączania nigdy się nie zakończyła.

To wyjaśnia także, dlaczego obecne wytyczne sugerują unikanie tej konwencji, gdy nadzór może śledzić proces główny bezpośrednio. Te wytyczne nie są zgodą na zmianę typu spakowanej jednostki, ponieważ zachowanie demona na pierwszym planie, przy rozwidleniu lub przy powiadomieniu musi odpowiadać temu, co deklaruje jednostka. Zmień typ bez zmiany demona, a otrzymasz jednostkę, która zgłasza błąd, gdy tunel działa, albo odwrotnie. Dopasuj parę albo pozostaw oba. Dokumentacja usługi systemd opisuje ten podział własności.

Czyste wyłączenie a przerwane wyjście

Czyste zatrzymanie prosi demona o wyjście, czeka na niego i pozwala menedżerowi uprzątnąć własną księgowość. Przerwane wyjście, zabity proces lub restart w trakcie wyłączania pomijają części tej sekwencji, a plik jest tym, co zostaje. Znalezienie go po awarii mówi, że wyłączanie się nie zakończyło, a nie że coś nasłuchuje.

Porównaj znacznik czasu pliku z ostatnim rozruchem i z ostatnim zatrzymaniem jednostki.

Następnie sprawdź dowody na żywo bezpośrednio. Gniazdo przypisane do portu VPN i interfejs tunelu z adresem są dowodem, że coś działa, w sposób, w jaki plik tekstowy w katalogu czasu działania nigdy nie jest. Jeśli brakuje obu, nic nie działa, cokolwiek twierdzi plik.

Przestań usuwać plik z przyzwyczajenia

Usunięcie go to uzasadniony krok naprawczy, gdy ustalisz, że żadna instancja go nie posiada i że program startowy dokumentuje to zachowanie.

Jako stały nawyk przed uruchomieniem podważa sprawdzenie, które obchodzisz. Jeśli nieaktualne pliki wracają po każdym czystym zatrzymaniu, zapisujący i cykl życia wyłączania nie zgadzają się co do właściciela ścieżki, a ta niezgodność jest błędem wartym naprawy.

Utrzymuj niezależną drogę do hosta, uruchom jedną instancję przez jej normalny menedżer i przeczytaj pierwszy wynik. Następna osoba dostaje jednostkę, która albo działa, albo sama się wyjaśnia.