systemctl siger, at systemd ikke er PID 1: hvad så?

Når du kører systemctl start openvpn-client@office og får en besked om, at systemet ikke blev bootet med systemd, ligner det en servicefejl. Det er slet ikke en servicefejl: den systemctl, du kaldte, kan ikke finde en kørende manager at tale med, så intet om OpenVPN blev nogensinde undersøgt. sudo opretter ikke en manager, og det gør installation af en unit-fil heller ikke. Kommandoen og maskinen kommer fra to forskellige verdener, og fejlen er det eneste sted, hvor det kom til syne.

Start med at spørge, hvilken proces der ejer PID 1 der, hvor kommandoen kører, fordi svaret afgør, om units overhovedet findes.

Fejlen navngiver miljøet, ikke OpenVPN

systemctl er en klient, ikke en manager. Den forbinder til system-manageren over en socket, og når der ikke er nogen manager i den anden ende, udskriver den den besked, som folk indsætter i fora. ps -p 1 -o pid=,comm= viser, hvad der faktisk kører som PID 1, og svaret er ofte et shell, en init-wrapper eller containerens egen entrypoint. I den situation kan en unit-fil være helt gyldig og alligevel aldrig blive læst. At gentage kommandoen som root ændrer kun klientens legitimationsoplysninger.

Læs hele beskeden før den første linje. En fejl fra managerens egen side, som en manglende unit eller en mislykket betingelse, betyder, at du nåede en; denne fejl betyder, at du ikke gjorde.

WSL: at slå systemd til er en konfigurationsændring

WSL fik systemd-understøttelse i senere udgivelser, men funktionen slås til pr. distribution og kun der, hvor den installerede WSL-version understøtter den. wsl --version på Windows-siden fortæller, hvad du har, og distributionens /etc/wsl.conf indeholder en [boot]-sektion med systemd=true. Redigér den fil uden at fjerne de sektioner, der allerede er der, og genstart derefter WSL-instansen, så ændringen træder i kraft. wsl --shutdown stopper alle kørende distributioner, så gem dit arbejde først.

Når du har åbnet igen, skal du bekræfte manageren, før du rører OpenVPN-unitten: ps -p 1 -o comm= bør vise systemd. At slå systemd til giver ingen profil, ingen legitimationsoplysninger og ingen instansnavn, så den næste fejl vil handle om en af disse ting snarere end om PID 1.

Containere kører deres entrypoint, ikke units

En normal container starter det, som dens entrypoint eller kommando angiver, og den er ikke en maskine, der er bootet med systemd, uanset hvilke pakker du installerer. Tilføjer du systemctl til imaget, får du en klient uden noget at forbinde til. For Community OpenVPN er det understøttede mønster normalt en forgrundsproces, openvpn --config /path/to/client.conf, startet af entrypointet og overvåget udefra. Den ejer håndterer opstart, signaler og nedlukning, og den bør være det eneste, der styrer tunnelen.

Start aldrig en interaktiv kopi ved siden af et entrypoint, der allerede styrer tunnelen, fordi to processer vil slås om enheden og ruterne. En minimal init-proces inde i containeren høster børn og videresender signaler; den gør ikke imaget til en vært med units.

Hvis en udrulning virkelig har brug for systemd inde i en container, kræver det et bevidst designet image, ikke ekstra privilegier, der tilføjes, indtil systemctl holder op med at klage.

Læs den næste fejl, når manageren findes

Når en rigtig manager starter tjenesten, begynder de nyttige fejl. En fejl i enhedstilladelser, en konfigurationsparsefejl, en manglende legitimationsoplysning og en peer, der ikke kan nås, er fire forskellige problemer, som PID 1-beskeden aldrig testede. Læs dem i den rækkefølge, uniten producerede dem, med journalctl -u openvpn-client@office -n 50 på en systemd-vært, eller ved at køre klienten i forgrunden der, hvor der ikke er nogen manager. Kørslen i forgrunden er også den hurtigste måde at bekræfte, at selve profilen virker.

Hold de to miljøer adskilt i dine noter: værten, der kører tunnelen, og det sted, hvor du skriver kommandoer.