systemctl tvrdí, že systemd není PID 1: co teď?

Spuštění systemctl start openvpn-client@office a zpráva, že systém nebyl nabootován se systemd, vypadá jako selhání služby. Není to ale selhání služby: systemctl, které jste zavolali, nenajde běžícího správce, se kterým by mluvilo, takže se o OpenVPN vůbec nic nezkoumalo. sudo správce nevytváří a instalace souboru unit ho také nevytvoří. Příkaz a stroj pocházejí ze dvou různých světů a chyba je jediné místo, kde se to ukázalo.

Začněte otázkou, který proces vlastní PID 1 tam, kde se příkaz spouští, protože tato odpověď rozhoduje o tom, zda unit vůbec existují.

Chyba pojmenovává prostředí, ne OpenVPN

systemctl je klient, ne správce. Připojuje se k systémovému správci přes socket, a když na druhé straně žádný správce není, vypíše zprávu, kterou lidé vkládají na fóra. ps -p 1 -o pid=,comm= ukazuje, co skutečně běží jako PID 1, a odpovědí je často shell, init obal nebo vlastní vstupní bod kontejneru. V takové situaci může být soubor unit zcela platný, a přesto se nikdy nepřečte. Opakování příkazu jako root mění jen přihlašovací údaje klienta.

Přečtěte si celou zprávu před prvním řádkem. Chyba od samotného správce, například chybějící unit nebo nesplněná podmínka, znamená, že jste se k němu dostali; tato chyba znamená, že ne.

WSL: zapnutí systemd je změna konfigurace

WSL získal podporu systemd v pozdějších verzích, ale funkce se zapíná pro každou distribuci zvlášť a jen tam, kde ji nainstalovaná verze WSL podporuje. wsl --version na straně Windows ukáže, co máte, a /etc/wsl.conf distribuce obsahuje [boot] sekci s systemd=true. Upravte tento soubor, aniž byste zahodili už přítomné sekce, a potom restartujte instanci WSL, aby se změna projevila. wsl --shutdown zastaví všechny běžící distribuce, takže nejdřív uložte práci.

Po opětovném otevření potvrďte správce, než se dotknete unit pro OpenVPN: ps -p 1 -o comm= by mělo hlásit systemd. Zapnutí systemd nedodá žádný profil, žádné přihlašovací údaje ani název instance, takže další chyba se bude týkat jednoho z toho, ne PID 1.

Kontejnery spouštějí svůj vstupní bod, ne unity

Běžný kontejner spustí to, co určí jeho vstupní bod nebo příkaz, a není to stroj nabootovaný se systemd, ať instalujete jakékoli balíčky. Přidání systemctl do image vám dá klienta, ke kterému se není kam připojit. Pro Community OpenVPN je podporovaný vzor obvykle proces v popředí, openvpn --config /path/to/client.conf, spuštěný vstupním bodem a sledovaný zvenčí. Tento vlastník se stará o start, signály a vypnutí a měl by být jediný, kdo tunel spravuje.

Nikdy nespouštějte interaktivní kopii vedle vstupního bodu, který už ten tunel spravuje, protože dva procesy se budou přetahovat o zařízení a trasy. Minimální init proces uvnitř kontejneru sklízí potomky a předává signály; nepřemění image na hostitele s unity.

Pokud nasazení opravdu potřebuje systemd uvnitř kontejneru, potřebuje image záměrně navrženou pro to, ne další oprávnění přidávaná, dokud si systemctl nepřestane stěžovat.

Přečtěte si další chybu, až správce existuje

Jakmile skutečný správce spustí službu, začnou užitečné chyby. Selhání oprávnění k zařízení, chyba při parsování konfigurace, chybějící přihlašovací údaj a nedostupný protějšek jsou čtyři různé problémy, které zpráva o PID 1 nikdy netestovala. Čtěte je v pořadí, v jakém je unit vytvořil, pomocí journalctl -u openvpn-client@office -n 50 na hostiteli se systemd, nebo spuštěním klienta v popředí tam, kde žádný správce není. Spuštění v popředí je také nejrychlejší způsob, jak potvrdit, že samotný profil funguje.

V poznámkách držte obě prostředí odděleně: hostitele, který spouští tunel, a místo, kde píšete příkazy.