systemctl meldet, systemd sei nicht PID 1: und dann?

Der Aufruf von systemctl start openvpn-client@office und die Meldung, das System sei nicht mit systemd gebootet worden, wirkt wie ein Dienstfehler. Es ist überhaupt kein Dienstfehler: Das systemctl, das Sie aufgerufen haben, findet keinen laufenden Manager, mit dem es sprechen könnte, also wurde nichts an OpenVPN untersucht. sudo erzeugt keinen Manager, und das Installieren einer Unit-Datei erzeugt auch keinen. Befehl und Maschine stammen aus zwei verschiedenen Welten, und der Fehler ist der einzige Ort, an dem das sichtbar wurde.

Fragen Sie zuerst, welcher Prozess dort PID 1 besitzt, wo der Befehl läuft, denn diese Antwort entscheidet, ob es überhaupt Units gibt.

Der Fehler benennt die Umgebung, nicht OpenVPN

systemctl ist ein Client, kein Manager. Es verbindet sich über einen Socket mit dem Systemmanager, und wenn am anderen Ende kein Manager ist, gibt es die Meldung aus, die Leute in Foren einfügen. ps -p 1 -o pid=,comm= zeigt, was tatsächlich als PID 1 läuft, und die Antwort ist oft eine Shell, ein Init-Wrapper oder der eigene Entrypoint des Containers. In dieser Lage kann eine Unit-Datei völlig gültig sein und trotzdem nie gelesen werden. Den Befehl als root zu wiederholen, ändert nur die Anmeldedaten des Clients.

Lesen Sie die ganze Meldung vor der ersten Zeile. Ein Fehler des Managers selbst, etwa eine fehlende Unit oder eine fehlgeschlagene Bedingung, bedeutet, dass Sie einen erreicht haben; dieser Fehler bedeutet, dass nicht.

WSL: systemd einzuschalten ist eine Konfigurationsänderung

WSL hat in späteren Versionen systemd-Unterstützung erhalten, aber die Funktion wird pro Distribution aktiviert und nur dort, wo die installierte WSL-Version sie unterstützt. wsl --version auf der Windows-Seite zeigt, was Sie haben, und die /etc/wsl.conf der Distribution enthält einen [boot]-Abschnitt mit systemd=true. Bearbeiten Sie diese Datei, ohne die bereits vorhandenen Abschnitte zu entfernen, und starten Sie dann die WSL-Instanz neu, damit die Änderung wirksam wird. wsl --shutdown beendet jede laufende Distribution, also speichern Sie zuerst Ihre Arbeit.

Nach dem erneuten Öffnen bestätigen Sie den Manager, bevor Sie die OpenVPN-Unit anfassen: ps -p 1 -o comm= sollte systemd melden. Das Einschalten von systemd liefert kein Profil, keine Anmeldedaten und keinen Instanznamen, also wird der nächste Fehler einen davon betreffen und nicht PID 1.

Container starten ihren Entrypoint, keine Units

Ein normaler Container startet, was sein Entrypoint oder sein Befehl vorgibt, und er ist keine mit systemd gebootete Maschine, egal welche Pakete Sie installieren. systemctl zum Image hinzuzufügen, liefert einen Client ohne etwas, womit er sich verbinden könnte. Für Community OpenVPN ist das unterstützte Muster meist ein Vordergrundprozess, openvpn --config /path/to/client.conf, vom Entrypoint gestartet und von außen überwacht. Dieser Eigentümer übernimmt Start, Signale und Shutdown, und er sollte das Einzige sein, was den Tunnel verwaltet.

Starten Sie niemals eine interaktive Kopie neben einem Entrypoint, der diesen Tunnel bereits verwaltet, denn zwei Prozesse werden um das Gerät und die Routen streiten. Ein minimaler Init-Prozess im Container erntet Kindprozesse und leitet Signale weiter; er macht das Image nicht zu einem Host mit Units.

Wenn ein Deployment systemd in einem Container wirklich braucht, braucht es ein bewusst dafür entworfenes Image, keine zusätzlichen Rechte, die hinzugefügt werden, bis systemctl aufhört zu klagen.

Lesen Sie den nächsten Fehler, sobald der Manager existiert

Sobald ein echter Manager den Dienst startet, beginnen die nützlichen Fehler. Ein Geräteberechtigungsfehler, ein Konfigurations-Parsefehler, fehlende Anmeldedaten und ein nicht erreichbarer Peer sind vier verschiedene Probleme, die die PID-1-Meldung nie geprüft hat. Lesen Sie sie in der Reihenfolge, in der die Unit sie erzeugt hat, mit journalctl -u openvpn-client@office -n 50 auf einem systemd-Host oder indem Sie den Client im Vordergrund starten, wo es keinen Manager gibt. Der Vordergrundlauf ist auch der schnellste Weg zu bestätigen, dass das Profil selbst funktioniert.

Halten Sie beide Umgebungen in Ihren Notizen getrennt: den Host, der den Tunnel betreibt, und den Ort, an dem Sie Befehle tippen.