systemctl säger att systemd inte är PID 1: vad då?

När du kör systemctl start openvpn-client@office och får ett meddelande om att systemet inte startades med systemd ser det ut som ett tjänstefel. Det är alls inget tjänstefel: den systemctl du anropade hittar ingen körande hanterare att prata med, så ingenting om OpenVPN undersöktes. sudo skapar ingen hanterare, och det gör inte installation av en unit-fil heller. Kommandot och maskinen kommer från två olika världar, och felet är den enda platsen där det blev synligt.

Börja med att fråga vilken process som äger PID 1 där kommandot körs, eftersom svaret avgör om unit-filer ens finns.

Felet namnger miljön, inte OpenVPN

systemctl är en klient, inte en hanterare. Den ansluter till systemhanteraren via en socket, och när det inte finns någon hanterare i andra ändan skriver den ut meddelandet som folk klistrar in i forum. ps -p 1 -o pid=,comm= visar vad som faktiskt körs som PID 1, och svaret är ofta ett shell, ett init-omslag eller containerns egen startpunkt. I en sådan situation kan en unit-fil vara helt giltig och ändå aldrig läsas. Att upprepa kommandot som root ändrar bara klientens inloggningsuppgifter.

Läs hela meddelandet före den första raden. Ett fel från hanteraren själv, som en saknad unit eller ett misslyckat villkor, betyder att du nådde en; det här felet betyder att du inte gjorde det.

WSL: att slå på systemd är en konfigurationsändring

WSL fick stöd för systemd i senare versioner, men funktionen slås på per distribution och bara där den installerade WSL-versionen stöder den. wsl --version på Windows-sidan visar vad du har, och distributionens /etc/wsl.conf innehåller en [boot]-sektion med systemd=true. Redigera den filen utan att ta bort sektionerna som redan finns, och starta sedan om WSL-instansen så att ändringen träder i kraft. wsl --shutdown stoppar varje körande distribution, så spara arbetet först.

När du har öppnat den igen, bekräfta hanteraren innan du rör OpenVPN-uniten: ps -p 1 -o comm= bör visa systemd. Att slå på systemd ger ingen profil, inga inloggningsuppgifter och inget instansnamn, så nästa fel kommer att handla om något av det och inte om PID 1.

Containrar kör sin startpunkt, inte units

En vanlig container startar det som dess startpunkt eller kommando anger, och den är inte en maskin som startats med systemd, oavsett vilka paket du installerar. Lägger du till systemctl i imagen får du en klient utan något att ansluta till. För Community OpenVPN är det stödda mönstret vanligen en process i förgrunden, openvpn --config /path/to/client.conf, startad av startpunkten och övervakad utifrån. Den ägaren hanterar start, signaler och avstängning, och den bör vara det enda som hanterar tunneln.

Starta aldrig en interaktiv kopia bredvid en startpunkt som redan hanterar den tunneln, eftersom två processer kommer att slåss om enheten och rutterna. En minimal init-process i containern skördar barn och vidarebefordrar signaler; den gör inte imagen till en värd med units.

Om en utrullning verkligen behöver systemd i en container behöver den en medvetet designad image, inte extra behörigheter som läggs till förrän systemctl slutar klaga.

Läs nästa fel när hanteraren finns

Så snart en riktig hanterare startar tjänsten börjar de användbara felen. Ett fel i enhetsbehörigheter, ett konfigurationstolkningsfel, saknade inloggningsuppgifter och en peer som inte går att nå är fyra olika problem som PID 1-meddelandet aldrig testade. Läs dem i den ordning uniten producerade dem, med journalctl -u openvpn-client@office -n 50 på en systemd-värd, eller genom att köra klienten i förgrunden där ingen hanterare finns. Körning i förgrunden är också det snabbaste sättet att bekräfta att själva profilen fungerar.

Håll de två miljöerna åtskilda i dina anteckningar: värden som kör tunneln, och platsen där du skriver kommandon.