systemctl thotë se systemd nuk është PID 1: po pastaj?

Kur systemctl start openvpn-client@office ekzekutohet dhe merret një mesazh se sistemi nuk u nis me systemd, duket si dështim i shërbimit. Nuk është aspak dështim i shërbimit: systemctl, të cilin thirrët, nuk gjen asnjë menaxher në punë për të biseduar, prandaj asgjë për OpenVPN nuk u shqyrtua. sudo nuk krijon menaxher, dhe instalimi i një skedari unit nuk krijon një të tillë. Komanda dhe makina vijnë nga dy botë të ndryshme, dhe gabimi është i vetmi vend ku kjo u shfaq.

Filloni duke pyetur se cili proces zotëron PID 1 aty ku ekzekutohet komanda, sepse kjo përgjigje vendos nëse unit ekzistojnë fare.

Gabimi emërton mjedisin, jo OpenVPN

systemctl është klient, jo menaxher. Lidhet me menaxherin e sistemit përmes një socket, dhe kur në anën tjetër nuk ka menaxher, shtyp mesazhin që njerëzit ngjitin në forume. ps -p 1 -o pid=,comm= tregon se çfarë ekzekutohet vërtet si PID 1, dhe përgjigja është shpesh një shell, një mbështjellës init ose pika e hyrjes e vetë kontejnerit. Në një situatë të tillë një skedar unit mund të jetë plotësisht i vlefshëm dhe megjithatë të mos lexohet kurrë. Përsëritja e komandës si root ndryshon vetëm kredencialet e klientit.

Lexoni të gjithë mesazhin përpara rreshtit të parë. Një gabim nga vetë menaxheri, si një unit që mungon ose një kusht i dështuar, do të thotë që arritët te një; ky gabim do të thotë që nuk arritët.

WSL: aktivizimi i systemd është ndryshim konfigurimi

WSL mori mbështetje për systemd në versione më të vona, por funksioni aktivizohet për çdo shpërndarje veç e veç dhe vetëm aty ku versioni i instaluar i WSL e mbështet. wsl --version në anën e Windows tregon çfarë keni, dhe /etc/wsl.conf e shpërndarjes përmban [boot] një seksion me systemd=true. Redaktoni atë skedar pa hequr seksionet që ekzistojnë tashmë, pastaj rinisni instancën WSL që ndryshimi të hyjë në fuqi. wsl --shutdown ndalon çdo shpërndarje në punë, prandaj ruani punën tuaj së pari.

Pasi ta rihapni, konfirmoni menaxherin përpara se të prekni unit-in e OpenVPN: ps -p 1 -o comm= duhet të tregojë systemd. Aktivizimi i systemd nuk jep profil, kredenciale ose emër instance, prandaj gabimi tjetër do të ketë të bëjë me një prej tyre dhe jo me PID 1.

Kontejnerët ekzekutojnë pikën e hyrjes së tyre, jo unit

Një kontejner normal nis atë që përcakton pika e hyrjes ose komanda e tij, dhe nuk është makinë e nisur me systemd, cilado paketë që instaloni. Shtimi i systemctl te imazhi ju jep një klient pa asgjë për t'u lidhur. Për Community OpenVPN modeli i mbështetur është zakonisht një proces në plan të parë, openvpn --config /path/to/client.conf, i nisur nga pika e hyrjes dhe i mbikëqyrur nga jashtë. Ai pronar merret me nisjen, sinjalet dhe ndalimin, dhe duhet të jetë e vetmja gjë që administron tunelin.

Kurrë mos nisni një kopje interaktive pranë një pike hyrjeje që tashmë administron atë tunel, sepse dy procese do të zihen për pajisjen dhe rrugët. Një proces init minimal brenda kontejnerit mbledh fëmijët dhe përcjell sinjale; nuk e kthen imazhin në një host me unit.

Nëse një vendosje ka vërtet nevojë për systemd brenda një kontejneri, i duhet një imazh i projektuar me qëllim për këtë, jo privilegje shtesë që shtohen derisa systemctl të ndalojë së ankuari.

Lexoni gabimin tjetër kur menaxheri ekziston

Sapo një menaxher i vërtetë nis shërbimin, fillojnë gabimet e dobishme. Dështim i lejes së pajisjes, gabim i analizimit të konfigurimit, kredenciale që mungojnë dhe një partner i paarritshëm janë katër probleme të ndryshme që mesazhi për PID 1 nuk i testoi kurrë. Lexoni ato sipas rendit që unit-i prodhoi, duke përdorur journalctl -u openvpn-client@office -n 50 në një host systemd, ose duke ekzekutuar klientin në plan të parë aty ku nuk ka menaxher. Ekzekutimi në plan të parë është gjithashtu mënyra më e shpejtë për të konfirmuar se vetë profili funksionon.

Mbajini dy mjediset të ndara në shënimet tuaja: hosti që ekzekuton tunelin dhe vendi ku shkruani komandat.