Als je systemctl start openvpn-client@office uitvoert en de melding krijgt dat het systeem niet met systemd is opgestart, lijkt dat op een dienstfout. Het is helemaal geen dienstfout: de systemctl die je hebt aangeroepen vindt geen draaiende beheerder om mee te praten, dus er is niets aan OpenVPN onderzocht. sudo maakt geen beheerder aan, en het installeren van een unit-bestand doet dat ook niet. De opdracht en de machine komen uit twee verschillende werelden, en de fout is de enige plek waar dat zichtbaar werd.

Begin met de vraag welk proces PID 1 bezit waar de opdracht draait, want dat antwoord bepaalt of er eigenlijk units bestaan.

De fout noemt de omgeving, niet OpenVPN

systemctl is een client, geen beheerder. Het verbindt met de systeembeheerder via een socket, en als er aan de andere kant geen beheerder is, drukt het de melding af die mensen in forums plakken. ps -p 1 -o pid=,comm= laat zien wat er werkelijk als PID 1 draait, en het antwoord is vaak een shell, een init-wrapper of het eigen entrypoint van de container. In die situatie kan een unit-bestand volledig geldig zijn en toch nooit worden gelezen. De opdracht als root herhalen verandert alleen de inloggegevens van de client.

Lees het hele bericht vóór de eerste regel. Een fout van de beheerder zelf, zoals een ontbrekende unit of een mislukte voorwaarde, betekent dat je er een hebt bereikt; deze fout betekent dat je dat niet hebt.

WSL: systemd inschakelen is een configuratiewijziging

WSL kreeg in latere releases ondersteuning voor systemd, maar de functie wordt per distributie ingeschakeld en alleen waar de geïnstalleerde WSL-versie die ondersteunt. wsl --version aan de Windows-kant laat zien wat je hebt, en het /etc/wsl.conf van de distributie bevat [boot] een sectie met systemd=true. Bewerk dat bestand zonder de al aanwezige secties te verwijderen, en herstart daarna de WSL-instantie zodat de wijziging van kracht wordt. wsl --shutdown stopt elke draaiende distributie, dus sla je werk eerst op.

Nadat je het opnieuw hebt geopend, bevestig je de beheerder voordat je de OpenVPN-unit aanraakt: ps -p 1 -o comm= zou systemd moeten tonen. Het inschakelen van systemd levert geen profiel, geen inloggegevens en geen instantienaam, dus de volgende fout gaat over een daarvan en niet over PID 1.

Containers starten hun entrypoint, geen units

Een normale container start wat het entrypoint of de opdracht bepaalt, en het is geen machine die met systemd is opgestart, welke pakketten je ook installeert. systemctl aan de image toevoegen geeft je een client zonder iets om verbinding mee te maken. Voor Community OpenVPN is het ondersteunde patroon meestal een proces op de voorgrond, openvpn --config /path/to/client.conf, gestart door het entrypoint en van buitenaf bewaakt. Die eigenaar regelt het starten, de signalen en het afsluiten, en het zou het enige moeten zijn dat de tunnel beheert.

Start nooit een interactieve kopie naast een entrypoint dat die tunnel al beheert, want twee processen zullen vechten om het apparaat en de routes. Een minimaal init-proces in de container ruimt kinderen op en geeft signalen door; het maakt van de image geen host met units.

Als een uitrol echt systemd in een container nodig heeft, heeft die een bewust ontworpen image nodig, geen extra rechten die worden toegevoegd totdat systemctl ophoudt met klagen.

Lees de volgende fout zodra de beheerder bestaat

Zodra een echte beheerder de dienst start, beginnen de nuttige fouten. Een apparaatrechtenfout, een configuratie-parsefout, ontbrekende inloggegevens en een onbereikbare peer zijn vier verschillende problemen die het PID 1-bericht nooit heeft getest. Lees ze in de volgorde waarin de unit ze heeft geproduceerd, met journalctl -u openvpn-client@office -n 50 op een systemd-host, of door de client op de voorgrond te draaien waar geen beheerder is. Draaien op de voorgrond is ook de snelste manier om te bevestigen dat het profiel zelf werkt.

Houd de twee omgevingen gescheiden in je notities: de host die de tunnel draait, en de plek waar je opdrachten typt.

Gerelateerde artikelen