systemctl twierdzi, że systemd nie jest PID 1: co dalej?

Gdy systemctl start openvpn-client@office zostanie uruchomione i pojawi się komunikat, że system nie został uruchomiony z systemd, wygląda to na awarię usługi. To wcale nie jest awaria usługi: systemctl, który wywołałeś, nie znajduje działającego menedżera, z którym mógłby rozmawiać, więc niczego dotyczącego OpenVPN nie sprawdzono. sudo nie tworzy menedżera, a instalacja pliku unit również go nie tworzy. Polecenie i maszyna pochodzą z dwóch różnych światów, a błąd jest jedynym miejscem, w którym to się ujawniło.

Zacznij od pytania, który proces posiada PID 1 tam, gdzie uruchamiane jest polecenie, bo ta odpowiedź decyduje, czy pliki unit w ogóle istnieją.

Błąd nazywa środowisko, a nie OpenVPN

systemctl to klient, a nie menedżer. Łączy się z menedżerem systemu przez gniazdo, a gdy po drugiej stronie nie ma menedżera, wypisuje komunikat, który ludzie wklejają na fora. ps -p 1 -o pid=,comm= pokazuje, co naprawdę działa jako PID 1, a odpowiedzią często jest powłoka, otoczka init albo własny punkt wejścia kontenera. W takiej sytuacji plik unit może być całkowicie poprawny i mimo to nigdy nie zostać odczytany. Powtórzenie polecenia jako root zmienia tylko dane logowania klienta.

Przeczytaj cały komunikat przed pierwszą linią. Błąd samego menedżera, na przykład brakujący unit albo niespełniony warunek, oznacza, że do niego dotarłeś; ten błąd oznacza, że nie.

WSL: włączenie systemd to zmiana konfiguracji

WSL otrzymał obsługę systemd w późniejszych wydaniach, ale funkcja jest włączana dla każdej dystrybucji osobno i tylko tam, gdzie obsługuje ją zainstalowana wersja WSL. wsl --version po stronie Windows pokazuje, co masz, a /etc/wsl.conf dystrybucji zawiera [boot] sekcję z systemd=true. Edytuj ten plik bez usuwania już obecnych sekcji, a następnie uruchom ponownie instancję WSL, aby zmiana zaczęła obowiązywać. wsl --shutdown zatrzymuje każdą działającą dystrybucję, więc najpierw zapisz pracę.

Po ponownym otwarciu potwierdź menedżera, zanim dotkniesz pliku unit OpenVPN: ps -p 1 -o comm= powinno pokazać systemd. Włączenie systemd nie daje profilu, danych logowania ani nazwy instancji, więc następny błąd będzie dotyczył jednego z nich, a nie PID 1.

Kontenery uruchamiają swój punkt wejścia, a nie pliki unit

Zwykły kontener uruchamia to, co określa jego punkt wejścia lub polecenie, i nie jest maszyną uruchomioną z systemd, niezależnie od tego, jakie pakiety zainstalujesz. Dodanie systemctl do obrazu daje klienta, który nie ma się z czym połączyć. W Community OpenVPN obsługiwanym wzorcem jest zwykle proces na pierwszym planie, openvpn --config /path/to/client.conf, uruchamiany przez punkt wejścia i nadzorowany z zewnątrz. Ten właściciel zajmuje się startem, sygnałami i zatrzymaniem, i powinien być jedyną rzeczą zarządzającą tunelem.

Nigdy nie uruchamiaj interaktywnej kopii obok punktu wejścia, który już zarządza tym tunelem, ponieważ dwa procesy będą walczyć o urządzenie i trasy. Minimalny proces init w kontenerze zbiera dzieci i przekazuje sygnały; nie zamienia obrazu w host z plikami unit.

Jeśli wdrożenie naprawdę potrzebuje systemd w kontenerze, potrzebuje obrazu zaprojektowanego specjalnie do tego, a nie dodatkowych uprawnień dodawanych, dopóki systemctl nie przestanie narzekać.

Przeczytaj następny błąd, gdy menedżer istnieje

Gdy prawdziwy menedżer uruchomi usługę, zaczynają się użyteczne błędy. Błąd uprawnień urządzenia, błąd analizy konfiguracji, brakujące dane logowania i nieosiągalny peer to cztery różne problemy, których komunikat o PID 1 nigdy nie sprawdził. Czytaj je w kolejności, w jakiej utworzył je unit, używając journalctl -u openvpn-client@office -n 50 na hoście systemd albo uruchamiając klienta na pierwszym planie tam, gdzie nie ma menedżera. Uruchomienie na pierwszym planie to także najszybszy sposób potwierdzenia, że sam profil działa.

Trzymaj oba środowiska osobno w notatkach: host, który uruchamia tunel, i miejsce, w którym wpisujesz polecenia.