systemctl sako, kad systemd nėra PID 1: o kas toliau?

Kai systemctl start openvpn-client@office paleidžiama ir gaunamas pranešimas, kad sistema nebuvo paleista su systemd, tai atrodo kaip paslaugos gedimas. Tai visai ne paslaugos gedimas: systemctl, kurį iškvietėte, neranda veikiančio valdytojo, su kuriuo galėtų kalbėtis, todėl nieko apie OpenVPN nebuvo patikrinta. sudo nesukuria valdytojo, o unit failo įdiegimas jo taip pat nesukuria. Komanda ir mašina ateina iš dviejų skirtingų pasaulių, o klaida yra vienintelė vieta, kur tai pasimatė.

Pradėkite nuo klausimo, kuris procesas valdo PID 1 ten, kur vykdoma komanda, nes šis atsakymas nulemia, ar unit failai apskritai egzistuoja.

Klaida įvardija aplinką, o ne OpenVPN

systemctl yra klientas, o ne valdytojas. Jis jungiasi prie sistemos valdytojo per socket, o kai kitoje pusėje nėra valdytojo, jis išspausdina pranešimą, kurį žmonės įklijuoja forumuose. ps -p 1 -o pid=,comm= parodo, kas iš tikrųjų veikia kaip PID 1, o atsakymas dažnai yra shell, init apvalkalas arba paties konteinerio įėjimo taškas. Tokioje situacijoje unit failas gali būti visiškai galiojantis ir vis tiek niekada neperskaitytas. Komandos kartojimas kaip root pakeičia tik kliento prisijungimo duomenis.

Perskaitykite visą pranešimą prieš pirmą eilutę. Valdytojo klaida, pavyzdžiui, trūkstamas unit arba nepavykusi sąlyga, reiškia, kad pasiekėte valdytoją; ši klaida reiškia, kad nepasiekėte.

WSL: systemd įjungimas yra konfigūracijos pakeitimas

WSL gavo systemd palaikymą vėlesnėse versijose, bet funkcija įjungiama atskirai kiekvienam platinimui ir tik ten, kur ją palaiko įdiegta WSL versija. wsl --version Windows pusėje parodo, ką turite, o platinimo /etc/wsl.conf faile yra [boot] sekcija su systemd=true. Redaguokite tą failą nepašalindami jau esamų sekcijų, tada iš naujo paleiskite WSL egzempliorių, kad pakeitimas įsigaliotų. wsl --shutdown sustabdo kiekvieną veikiantį platinimą, todėl pirmiausia išsaugokite darbą.

Po pakartotinio atidarymo patvirtinkite valdytoją prieš liesdami OpenVPN unit: ps -p 1 -o comm= turėtų rodyti systemd. systemd įjungimas nesuteikia profilio, prisijungimo duomenų ar egzemplioriaus pavadinimo, todėl kita klaida bus apie vieną iš jų, o ne apie PID 1.

Konteineriai paleidžia savo įėjimo tašką, o ne unit failus

Įprastas konteineris paleidžia tai, ką nustato jo įėjimo taškas arba komanda, ir tai nėra su systemd paleista mašina, kad ir kokius paketus įdiegtumėte. Pridėjus systemctl prie atvaizdo, gausite klientą, kuriam nėra prie ko prisijungti. Community OpenVPN atveju palaikomas šablonas paprastai yra pirmame plane veikiantis procesas, openvpn --config /path/to/client.conf, kurį paleidžia įėjimo taškas ir kuris prižiūrimas iš išorės. Tas savininkas tvarko paleidimą, signalus ir išjungimą, ir jis turėtų būti vienintelis, kas valdo tunelį.

Niekada nepaleiskite interaktyvios kopijos šalia įėjimo taško, kuris jau valdo tą tunelį, nes du procesai kovos dėl įrenginio ir maršrutų. Minimalus init procesas konteinerio viduje surenka vaikus ir persiunčia signalus; jis nepaverčia atvaizdo hostu su unit failais.

Jei diegimui tikrai reikia systemd konteinerio viduje, jam reikia sąmoningai sukurto atvaizdo, o ne papildomų privilegijų, pridedamų tol, kol systemctl nustos skųstis.

Perskaitykite kitą klaidą, kai valdytojas egzistuoja

Kai tik tikras valdytojas paleidžia paslaugą, prasideda naudingos klaidos. Įrenginio leidimo gedimas, konfigūracijos analizės klaida, trūkstami prisijungimo duomenys ir nepasiekiamas partneris yra keturios skirtingos problemos, kurių PID 1 pranešimas niekada netikrino. Skaitykite jas ta tvarka, kuria unit jas sukūrė, naudodami journalctl -u openvpn-client@office -n 50 systemd hoste arba paleisdami klientą pirmame plane ten, kur valdytojo nėra. Paleidimas pirmame plane taip pat yra greičiausias būdas patvirtinti, kad pats profilis veikia.

Laikykite abi aplinkas atskirai savo užrašuose: hostą, kuriame veikia tunelis, ir vietą, kur rašote komandas.