As jy systemctl start openvpn-client@office laat loop en 'n boodskap kry dat die stelsel nie met systemd opgestart is nie, lyk dit soos 'n diensfout. Dit is glad nie 'n diensfout nie: die systemctl wat jy aangeroep het, kan nie 'n lopende bestuurder vind om mee te praat nie, so niks aangaande OpenVPN is ooit ondersoek nie. sudo skep nie 'n bestuurder nie, en om 'n unit-lêer te installeer doen dit ook nie. Die opdrag en die masjien kom uit twee verskillende wêrelde, en die fout is die enigste plek waar dit opgemerk is.

Begin deur te vra watter proses PID 1 besit waar die opdrag loop, want dié antwoord bepaal of units hoegenaamd bestaan.

Die fout noem die omgewing, nie OpenVPN nie

systemctl is 'n kliënt, nie 'n bestuurder nie. Dit koppel oor 'n socket aan die stelselbestuurder, en wanneer daar geen bestuurder aan die ander kant is nie, druk dit die boodskap wat mense in forums plak. ps -p 1 -o pid=,comm= wys wat werklik as PID 1 loop, en die antwoord is dikwels 'n shell, 'n init-omhulsel of die houer se eie entrypoint. In daardie geval kan 'n unit-lêer heeltemal geldig wees en tog nooit gelees word nie. Om die opdrag as root te herhaal, verander net die geloofsbriewe van die kliënt.

Lees die hele boodskap voor die eerste reël. 'n Fout van die bestuurder self, soos 'n ontbrekende unit of 'n mislukte voorwaarde, beteken jy het een bereik; hierdie fout beteken jy het dit nie.

WSL: om systemd te aktiveer is 'n konfigurasiewysiging

WSL het in latere weergawes systemd-ondersteuning gekry, maar die funksie word per verspreiding geaktiveer en net waar die geïnstalleerde WSL-weergawe dit ondersteun. wsl --version aan die Windows-kant wys wat jy het, en die verspreiding se /etc/wsl.conf bevat 'n [boot]-afdeling met systemd=true. Wysig daardie lêer sonder om die afdelings wat al daar is te verloor, en herbegin dan die WSL-instansie sodat die wysiging in werking tree. wsl --shutdown stop elke lopende verspreiding, so stoor eers jou werk.

Nadat jy dit weer oopgemaak het, bevestig die bestuurder voordat jy aan die OpenVPN-unit raak: ps -p 1 -o comm= behoort systemd te rapporteer. Om systemd aan te skakel, verskaf geen profiel, geen geloofsbrief en geen instansienaam nie, so die volgende fout sal oor een van daardie dinge gaan eerder as oor PID 1.

Houers laat hul entrypoint loop, nie units nie

'n Normale houer begin wat die entrypoint of die opdrag bepaal, en dit is nie 'n masjien wat met systemd opgestart is nie, maak nie saak watter pakkette jy installeer nie. Om systemctl by die beeld te voeg, gee jou 'n kliënt met niks om aan te koppel nie. Vir Community OpenVPN is die ondersteunde patroon gewoonlik 'n voorgrondproses, openvpn --config /path/to/client.conf, wat deur die entrypoint begin en van buite gemonitor word. Daardie eienaar hanteer die opstart, seine en afsluiting, en dit behoort die enigste ding te wees wat die tonnel bestuur.

Moenie 'n interaktiewe kopie langs 'n entrypoint begin wat daardie tonnel al bestuur nie, want twee prosesse sal oor die toestel en die roetes baklei. 'n Minimale init-proses in die houer oes kinders in en stuur seine aan, maar dit maak nie van die beeld 'n gasheer met units nie.

As 'n ontplooiing werklik systemd in 'n houer nodig het, het dit 'n doelbewus ontwerpte beeld nodig, nie ekstra voorregte wat bygevoeg word totdat systemctl ophou kla nie.

Lees die volgende fout sodra die bestuurder bestaan

Sodra 'n werklike bestuurder die diens begin, begin die nuttige foute. 'n Toesteltoestemmingsfout, 'n konfigurasie-parseerfout, 'n ontbrekende geloofsbrief en 'n onbereikbare eweknie is vier verskillende probleme wat die PID 1-boodskap nooit getoets het nie. Lees hulle in die orde waarin die unit hulle opgelewer het, met journalctl -u openvpn-client@office -n 50 op 'n systemd-gasheer, of deur die kliënt in die voorgrond te laat loop waar daar geen bestuurder is nie. Die voorgrondlopie is ook die vinnigste manier om te bevestig dat die profiel self werk.

Hou die twee omgewings apart in jou notas: die gasheer wat die tonnel laat loop, en die plek waar jy opdragte tik.

Verwante artikels