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

Dersom du kjører systemctl start openvpn-client@office og får en melding om at systemet ikke ble startet med systemd, virker det som en tjenestefeil. Det er på ingen måte en tjenestefeil: den systemctl du påkalte, finner ingen kjørende tjenestebehandler å snakke med, så ingenting om OpenVPN ble undersøkt. sudo oppretter ingen tjenestebehandler, og installasjon av en unit-fil gjør det heller ikke. Kommandoen og maskinen stammer fra to forskjellige verdener, og feilen er det eneste stedet hvor dette kom til syne.

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

Feilen navngir miljøet, ikke OpenVPN

systemctl er en klient, ikke en tjenestebehandler. Den kobler seg til systembehandleren via en socket, og når det ikke finnes noen behandler i den 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 oppstart. I en slik situasjon kan en unit-fil være fullstendig gyldig og likevel aldri bli lest. Gjentakelse av kommandoen som root endrer bare klientens påloggingsdetaljer.

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

WSL: å aktivere systemd er en konfigurasjonsendring

WSL fikk støtte for systemd i nyere utgivelser, men funksjonen aktiveres 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 filen uten å fjerne seksjonene som allerede er der, og start deretter WSL-forekomsten på nytt slik at endringen trer i kraft. wsl --shutdown stopper alle kjørende distribusjoner, så lagre arbeidet ditt først.

Når du har åpnet den igjen, bekreft behandleren før du berører OpenVPN-uniten: ps -p 1 -o comm= forventes å vise systemd. Aktivering av systemd gir verken profil, påloggingsdetaljer eller forekomstnavn, så den neste feilen vil dreie seg om en av disse og ikke om PID 1.

Containere starter oppstartspunktet sitt, ikke units

En vanlig container starter det oppstartspunktet eller kommandoen angir, og den er ikke en maskin som er startet med systemd, uansett hvilke pakker du installerer. Hvis du legger 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 oppstartspunktet og overvåket utenfra. Den eieren håndterer oppstart, signaler og nedstenging, og bør være det eneste som administrerer tunnelen.

Du må aldri starte en interaktiv kopi ved siden av et oppstartspunkt som allerede administrerer den tunnelen, fordi to prosesser vil kjempe om enheten og rutene. En minimal init-prosess i containeren sanker inn 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 utformet image, ikke ekstra privilegier som legges til helt til systemctl slutter å klage.

Les den neste feilen når behandleren eksisterer

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

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