systemctl saka, ka systemd nav PID 1: un kas tālāk?

Ja systemctl start openvpn-client@office palaižat un saņemat ziņu, ka sistēma nav startēta ar systemd, tas izskatās kā pakalpojuma kļūme. Tā nemaz nav pakalpojuma kļūme: systemctl, ko izsaucāt, nevar atrast darbojošos pārvaldnieku, ar ko runāt, tāpēc nekas par OpenVPN netika pārbaudīts. sudo neizveido pārvaldnieku, un arī unit faila instalēšana to neizveido. Komanda un mašīna nāk no divām dažādām pasaulēm, un kļūda ir vienīgā vieta, kur tas parādījās.

Sāciet ar jautājumu, kurš process pārvalda PID 1 tur, kur komanda darbojas, jo šī atbilde nosaka, vai unit vispār pastāv.

Kļūda nosauc vidi, nevis OpenVPN

systemctl ir klients, nevis pārvaldnieks. Tas savienojas ar sistēmas pārvaldnieku caur socket, un, ja otrā galā nav pārvaldnieka, tas izdrukā ziņu, ko cilvēki ielīmē forumos. ps -p 1 -o pid=,comm= parāda, kas patiešām darbojas kā PID 1, un atbilde bieži ir shell, init apvalks vai paša konteinera ieejas punkts. Šādā situācijā unit fails var būt pilnīgi derīgs un tomēr nekad netikt nolasīts. Komandas atkārtošana kā root maina tikai klienta akreditācijas datus.

Izlasiet visu ziņu pirms pirmās rindas. Pārvaldnieka kļūda, piemēram, trūkstošs unit vai neizdevies nosacījums, nozīmē, ka esat to sasniedzis; šī kļūda nozīmē, ka neesat.

WSL: systemd iespējošana ir konfigurācijas izmaiņa

WSL ieguva systemd atbalstu vēlākās versijās, bet funkcija tiek iespējota katram izplatījumam atsevišķi un tikai tur, kur to atbalsta instalētā WSL versija. wsl --version Windows pusē parāda, kas jums ir, un izplatījuma /etc/wsl.conf failā ir [boot] sadaļa ar systemd=true. Rediģējiet šo failu, neizdzēšot jau esošās sadaļas, pēc tam restartējiet WSL instanci, lai izmaiņa stātos spēkā. wsl --shutdown aptur katru darbojošos izplatījumu, tāpēc vispirms saglabājiet darbu.

Pēc atkārtotas atvēršanas apstipriniet pārvaldnieku, pirms aiztiekat OpenVPN unit: ps -p 1 -o comm= vajadzētu uzrādīt systemd. systemd iespējošana nesniedz profilu, akreditācijas datus vai instances nosaukumu, tāpēc nākamā kļūda būs par kādu no tiem, nevis par PID 1.

Konteinēri palaiž savu ieejas punktu, nevis unit

Parasts konteiners palaiž to, ko nosaka tā ieejas punkts vai komanda, un tas nav ar systemd startēta mašīna, lai kādas pakotnes jūs instalētu. Pievienojot systemctl attēlam, jūs iegūstat klientu, kuram nav ar ko savienoties. Community OpenVPN atbalstītais modelis parasti ir priekšplānā darbojošs process, openvpn --config /path/to/client.conf, ko palaiž ieejas punkts un ko uzrauga no ārpuses. Tas īpašnieks rūpējas par palaišanu, signāliem un izslēgšanu, un tam vajadzētu būt vienīgajam, kas pārvalda tuneli.

Nekad nepalaidiet interaktīvu kopiju blakus ieejas punktam, kas jau pārvalda šo tuneli, jo divi procesi cīnīsies par ierīci un maršrutiem. Minimāls init process konteinera iekšienē savāc bērnus un pārsūta signālus; tas nepārvērš attēlu par hostu ar unit.

Ja izvietošanai patiešām vajag systemd konteinera iekšienē, tai vajag apzināti projektētu attēlu, nevis papildu privilēģijas, ko pievieno, līdz systemctl pārstāj sūdzēties.

Lasiet nākamo kļūdu, kad pārvaldnieks pastāv

Tiklīdz īsts pārvaldnieks palaiž pakalpojumu, sākas noderīgās kļūdas. Ierīces atļaujas kļūme, konfigurācijas parsēšanas kļūda, trūkstoši akreditācijas dati un nesasniedzams partneris ir četras dažādas problēmas, ko ziņa par PID 1 nekad nav pārbaudījusi. Lasiet tās tādā secībā, kādā unit tās radīja, izmantojot journalctl -u openvpn-client@office -n 50 systemd hostā, vai palaižot klientu priekšplānā tur, kur pārvaldnieka nav. Palaišana priekšplānā ir arī ātrākais veids, kā apstiprināt, ka pats profils darbojas.

Turiet abas vides atsevišķi savās piezīmēs: hostu, kas palaiž tuneli, un vietu, kur rakstāt komandas.