systemctl seier at systemd ikkje er PID 1: kva så?

Når du køyrer systemctl start openvpn-client@office og får ei melding om at systemet ikkje vart starta med systemd, ser det ut som ein tenestefeil. Det er slett ikkje ein tenestefeil: den systemctl du kalla, finn ingen køyrande behandlar å snakke med, så ingenting om OpenVPN vart undersøkt. sudo opprettar ingen behandlar, og det gjer heller ikkje installasjon av ei unit-fil. Kommandoen og maskinen kjem frå to ulike verder, og feilen er den einaste staden der dette vart synleg.

Start med å spørje kva prosess som eig PID 1 der kommandoen køyrer, fordi svaret avgjer om unit-filer i det heile finst.

Feilen namngir miljøet, ikkje OpenVPN

systemctl er ein klient, ikkje ein behandlar. Han koplar til systembehandlaren over ein socket, og når det ikkje finst nokon behandlar i andre enden, skriv han ut meldinga folk limer inn i forum. ps -p 1 -o pid=,comm= viser kva som faktisk køyrer som PID 1, og svaret er ofte eit shell, ei init-innpakking eller sjølve inngangen til containeren. I ein slik situasjon kan ei unit-fil vere heilt gyldig og likevel aldri bli lesen. Å gjenta kommandoen som root endrar berre påloggingsinformasjonen til klienten.

Les heile meldinga før den første linja. Ein feil frå behandlaren sjølv, som ei manglande unit eller eit mislukka vilkår, betyr at du nådde ein; denne feilen betyr at du ikkje gjorde det.

WSL: å slå på systemd er ei konfigurasjonsendring

WSL fekk støtte for systemd i seinare utgåver, men funksjonen blir slått på per distribusjon og berre der den installerte WSL-versjonen støttar han. wsl --version på Windows-sida viser kva du har, og distribusjonen si /etc/wsl.conf inneheld ein [boot]-seksjon med systemd=true. Rediger den fila utan å fjerne seksjonane som allereie finst, og start deretter WSL-førekomsten på nytt slik at endringa trer i kraft. wsl --shutdown stoppar kvar køyrande distribusjon, så lagre arbeidet først.

Etter at du har opna ho igjen, stadfest behandlaren før du rører OpenVPN-uniten: ps -p 1 -o comm= skal vise systemd. Å slå på systemd gir ingen profil, påloggingsinformasjon eller førekomstnamn, så den neste feilen vil handle om ein av desse og ikkje om PID 1.

Containarar køyrer inngangspunktet sitt, ikkje units

Ein vanleg container startar det inngangspunktet eller kommandoen angir, og han er ikkje ein maskin starta med systemd, uansett kva pakkar du installerer. Legg du til systemctl i imaget, får du ein klient utan noko å kople til. For Community OpenVPN er det støtta mønsteret vanlegvis ein prosess i forgrunnen, openvpn --config /path/to/client.conf, starta av inngangspunktet og overvaka utanfrå. Den eigaren handterer oppstart, signal og nedstenging, og han bør vere det einaste som styrer tunnelen.

Start aldri ein interaktiv kopi ved sida av eit inngangspunkt som allereie styrer den tunnelen, fordi to prosessar vil kjempe om eininga og rutene. Ein minimal init-prosess inne i containeren haustar barn og videresender signal; han gjer ikkje imaget til ein vert med units.

Viss ei utrulling verkeleg treng systemd i ein container, treng ho eit medvite designa image, ikkje ekstra privilegium som blir lagde til heilt til systemctl sluttar å klage.

Les den neste feilen når behandlaren finst

Så snart ein ekte behandlar startar tenesta, byrjar dei nyttige feila. Ein feil i einingstillatingar, ein konfigurasjonsparsefeil, manglande påloggingsinformasjon og ein peer som ikkje kan nåast er fire ulike problem som PID 1-meldinga aldri testa. Les dei i den rekkjefølgja uniten produserte dei, med journalctl -u openvpn-client@office -n 50 på ein systemd-vert, eller ved å køyre klienten i forgrunnen der det ikkje finst nokon behandlar. Køyring i forgrunnen er også den raskaste måten å stadfeste at sjølve profilen fungerer.

Hald dei to miljøa åtskilde i notata dine: verten som køyrer tunnelen, og staden der du skriv kommandoar.