systemctl sier at systemd ikke er PID 1: hva så?

Når du kjører systemctl start openvpn-client@office og får en melding om at systemet ikke ble startet med systemd, ser det ut som en tjenestefeil. Det er slett ikke en tjenestefeil: den systemctl du kalte, finner ingen kjørende behandler å snakke med, så ingenting om OpenVPN ble undersøkt. sudo oppretter ingen behandler, og det gjør heller ikke installasjon av en unit-fil. Kommandoen og maskinen kommer fra to forskjellige verdener, og feilen er det eneste stedet der dette ble synlig.

Start med å spørre hvilken prosess som eier PID 1 der kommandoen kjører, fordi svaret avgjør om unit-filer i det hele tatt finnes.

Feilen navngir miljøet, ikke OpenVPN

systemctl er en klient, ikke en behandler. Den kobler til systembehandleren over en socket, og når det ikke finnes noen behandler i andre enden, skriver den ut meldingen folk limer inn i forum. ps -p 1 -o pid=,comm= viser hva som faktisk kjører som PID 1, og svaret er ofte et shell, en init-innpakning eller containerens egen inngang. I en slik situasjon kan en unit-fil være helt gyldig og likevel aldri bli lest. Å gjenta kommandoen som root endrer bare klientens påloggingsinformasjon.

Les hele meldingen før den første linjen. En feil fra behandleren selv, som en manglende unit eller en mislykket betingelse, betyr at du nådde en; denne feilen betyr at du ikke gjorde det.

WSL: å slå på systemd er en konfigurasjonsendring

WSL fikk støtte for systemd i senere utgivelser, men funksjonen slås på per distribusjon og bare der den installerte WSL-versjonen støtter den. wsl --version på Windows-siden viser hva du har, og distribusjonens /etc/wsl.conf inneholder en [boot]-seksjon med systemd=true. Rediger den filen uten å fjerne seksjonene som allerede finnes, og start deretter WSL-forekomsten på nytt slik at endringen trer i kraft. wsl --shutdown stopper hver kjørende distribusjon, så lagre arbeidet først.

Etter at du har åpnet den igjen, bekreft behandleren før du rører OpenVPN-uniten: ps -p 1 -o comm= skal vise systemd. Å slå på systemd gir ingen profil, påloggingsinformasjon eller forekomstnavn, så den neste feilen vil handle om en av disse og ikke om PID 1.

Containere kjører inngangspunktet sitt, ikke units

En vanlig container starter det inngangspunktet eller kommandoen angir, og den er ikke en maskin startet med systemd, uansett hvilke pakker du installerer. Legger du til systemctl i imaget, får du en klient uten noe å koble til. For Community OpenVPN er det støttede mønsteret vanligvis en prosess i forgrunnen, openvpn --config /path/to/client.conf, startet av inngangspunktet og overvåket utenfra. Den eieren håndterer oppstart, signaler og nedstenging, og den bør være det eneste som styrer tunnelen.

Start aldri en interaktiv kopi ved siden av et inngangspunkt som allerede styrer den tunnelen, fordi to prosesser vil kjempe om enheten og rutene. En minimal init-prosess inne i containeren høster barn og videresender signaler; den gjør ikke imaget til en vert med units.

Hvis en utrulling virkelig trenger systemd i en container, trenger den et bevisst designet image, ikke ekstra privilegier som legges til helt til systemctl slutter å klage.

Les den neste feilen når behandleren finnes

Så snart en ekte behandler starter tjenesten, begynner de nyttige feilene. En feil i enhetstillatelser, en konfigurasjonsparsefeil, manglende påloggingsinformasjon og en peer som ikke kan nås er fire ulike problemer som PID 1-meldingen aldri testet. Les dem i den rekkefølgen uniten produserte dem, med journalctl -u openvpn-client@office -n 50 på en systemd-vert, eller ved å kjøre klienten i forgrunnen der det ikke finnes noen behandler. Kjøring i forgrunnen er også den raskeste måten å bekrefte at selve profilen fungerer.

Hold de to miljøene atskilt i notatene dine: verten som kjører tunnelen, og stedet der du skriver kommandoer.