Jednostka -.mount jest zamaskowana: klient OpenVPN nie startuje

Twoja usługa zawodzi, zanim OpenVPN w ogóle się uruchomi, a błąd mówi o jednostce montowania, której nigdy nie konfigurowałeś. To jest wskazówka: systemd odrzuca całą transakcję, bo jednostka montowania głównego jest zamaskowana, a Twój profil VPN nie został jeszcze odczytany. Zwykłą przyczyną jest plik pozostawiony w katalogu jednostek czasu wykonania, a nie zepsuty fstab i nie brakujący certyfikat. Najpierw sprawdź plik, bo to najtańsze wyjaśnienie do wykluczenia.

Błąd wskazuje montowanie główne, nie Twój profil

systemd sam generuje jednostkę montowania głównego z informacji o montowaniu jądra i nazywa ją -.mount, ponieważ myślnik oznacza ścieżkę główną. Ta jednostka zwykle istnieje tylko w pamięci i nie ma za sobą żadnego pliku. Gdy błąd mówi, że jest zamaskowana, ktoś umieścił plik jednostki tam, gdzie systemd go wczyta, i wskazał ten plik na /dev/null. Maskowanie to realny stan, a nie literówka w komunikacie.

Jednostka instancji zawodzi, bo jej graf zadań dociera do montowania głównego przez kolejność i przez własne wymagania montowania. Transakcja jest odrzucana, zanim uruchomiony zostanie plik binarny OpenVPN, więc nic w konfiguracji klienta nie może być przyczyną. Dlatego zmiana profili, certyfikatów lub danych logowania nie ma żadnego wpływu na tę konkretną awarię.

Zajrzyj do katalogu czasu wykonania, zanim zaczniesz debugować OpenVPN

Poszukaj pliku o dokładnie tej nazwie w katalogu jednostek czasu wykonania, a potem zapytaj systemd, czym według niego jest ta jednostka. Obie odpowiedzi są szybkie, a razem oddzielają pozostawiony plik od prawdziwego problemu z montowaniem.

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

Normalna maszyna nie ma takiego pliku, a lista zamaskowanych nie zawiera montowania głównego. Jeśli pierwsze polecenie wypisze dowiązanie symboliczne do /dev/null, diagnoza jest pewna. Ten sam katalog może zawierać maskę tmp.mount utworzoną przez te same narzędzia, a to daje tę samą klasę awarii pod inną nazwą. Patrz na cały katalog, a nie tylko na nazwę z błędu.

ls -la /run/systemd/system/*.mount

Jeśli katalog jest czysty, a jednostka nadal jest zamaskowana, maska znajduje się gdzie indziej w ścieżce wyszukiwania, a systemctl cat -.mount pokaże, który plik jest wczytywany.

Usuń plik, wczytaj ponownie i uruchom od nowa

Wystarczy usunąć plik czasu wykonania i ponownie wczytać menedżera, a to nie dotyka niczego, co pochodzi z pakietu. Wczytaj ponownie przed uruchomieniem, bo systemd zachowuje stan wczytanej jednostki, dopóki nie odczyta katalogu ponownie.

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

Potem przeczytaj dziennik samej usługi, zamiast zakładać, że poprawka zadziałała. Czysty start dowodzi tylko, że systemd zaakceptował jednostkę; klient nadal może zginąć z powodu brakującego profilu, nieosiągalnego peera lub certyfikatu, który się nie waliduje. To zwykłe problemy OpenVPN, które były ukryte za zamaskowaną jednostką. Dziennik zapisuje, który profil został wczytany i czy tunel rzeczywiście powstał. Jeśli jednostka startuje, a tunel nie, trafiłeś na inny problem, i to jest postęp.

journalctl -u [email protected] -b --no-pager

Ponieważ /run to tymczasowy system plików, restart również usuwa ten plik. To czyni restart użytecznym testem: jeśli usługa działa po restarcie i znów zawodzi po kolejnym wdrożeniu, plik jest wpiekany w obraz.

Nie dopuść, by wrócił z obrazu

Szablon kontenera lub maszyny wirtualnej, który podczas budowania maskuje jednostki montowania, przeniesie tę maskę do każdego klonu. Następna rzecz, która potrzebuje systemu plików, psuje się, a komunikat obwinia montowanie zamiast obrazu, z którego pochodzi. Naprawa wewnątrz jednej działającej instancji ukrywa problem do chwili utworzenia kolejnej instancji.

Przeszukaj kontekst budowania pod kątem nazwy pliku i polecenia, które go tworzy, następnie usuń maskę z szablonu i zbuduj ponownie. Jeśli maska jest naprawdę potrzebna podczas budowania, usuń ją w tej samej warstwie, która kończy budowanie, aby wysyłany obraz startował czysto. Sprawdź na świeżym klonie, a nie na maszynie naprawianej ręcznie. To jedyny test, który dowodzi, że obraz się zmienił.

Objaw, który warto zapamiętać, to rozbieżność między błędem a tym, co konfigurowałeś. Gdy systemd narzeka na montowanie, a Ty uruchamiasz klienta VPN, najpierw przeczytaj nazwę jednostki w komunikacie, a dopiero potem nazwę usługi.