systemctl inasema systemd si PID 1: basi nini kingine?
Ujumbe wa PID 1 unahusu mazingira, si OpenVPN. Angalia kinachoendeshwa kama PID 1, washa systemd mahali inaposaidiwa, kisha soma hitilafu halisi.
Unapowasha systemctl start openvpn-client@office na kupata ujumbe kwamba mfumo haukuwashwa na systemd, inaonekana kama kushindwa kwa huduma. Hii si kushindwa kwa huduma hata kidogo: systemctl uliyoita haipati meneja anayefanya kazi wa kuzungumza naye, kwa hivyo hakuna chochote kuhusu OpenVPN kilichochunguzwa. sudo haitengenezi meneja, na kufunga faili ya unit hakuzalishi mmoja. Amri na mashine zinatoka katika dunia mbili tofauti, na hitilafu ndiyo mahali pekee palipoonyesha hilo.
Anza kwa kuuliza ni mchakato gani unamiliki PID 1 mahali amri inapoendeshwa, kwa sababu jibu hilo huamua kama unit zipo kabisa.
Hitilafu inataja mazingira, si OpenVPN
systemctl ni mteja, si meneja. Inaunganisha kwa meneja wa mfumo kupitia socket, na pale upande wa pili hakuna meneja inachapisha ujumbe ambao watu hubandika kwenye majukwaa. ps -p 1 -o pid=,comm= inaonyesha kinachoendeshwa kama PID 1 kwa kweli, na jibu mara nyingi ni shell, kifuniko cha init au mahali pa kuingia pa kontena yenyewe. Katika hali hiyo faili ya unit inaweza kuwa halali kabisa na bado isisomwe kamwe. Kurudia amri kama root hubadilisha tu vitambulisho vya mteja.
Soma ujumbe wote kabla ya mstari wa kwanza. Hitilafu kutoka kwa meneja mwenyewe, kama unit inayokosekana au sharti lililoshindwa, inamaanisha ulifika kwake; hitilafu hii inamaanisha hukufika.
WSL: kuwasha systemd ni mabadiliko ya usanidi
WSL ilipata usaidizi wa systemd katika matoleo ya baadaye, lakini kipengele hiki huwashwa kwa kila usambazaji kivyake na mahali tu ambapo toleo lililosakinishwa la WSL linaisaidia. wsl --version upande wa Windows inaonyesha ulivyo navyo, na /etc/wsl.conf ya usambazaji ina [boot] sehemu yenye systemd=true. Hariri faili hiyo bila kuondoa sehemu zilizopo tayari, kisha anzisha tena mfano wa WSL ili mabadiliko yatekelezwe. wsl --shutdown inasimamisha kila usambazaji unaoendesha, kwa hivyo hifadhi kazi yako kwanza.
Baada ya kuifungua tena, thibitisha meneja kabla ya kugusa unit ya OpenVPN: ps -p 1 -o comm= inapaswa kuonyesha systemd. Kuwasha systemd hakupi wasifu, vitambulisho au jina la mfano, kwa hivyo hitilafu inayofuata itahusu moja ya hayo, si PID 1.
Kontena huendesha mahali pa kuingia, si unit
Kontena ya kawaida huanzisha kile kinachoelezwa na mahali pake pa kuingia au amri, na si mashine iliyowashwa na systemd, haijalishi unasakinisha vifurushi gani. Kuongeza systemctl kwenye picha kunakupa mteja asiye na mahali pa kuunganisha. Kwa Community OpenVPN mtindo unaosaidiwa kwa kawaida ni mchakato unaoendesha mbele, openvpn --config /path/to/client.conf, unaoanzishwa na mahali pa kuingia na kusimamiwa kutoka nje. Mmiliki huyo hushughulikia kuanza, ishara na kuzima, na anapaswa kuwa kitu pekee kinachosimamia handaki.
Kamwe usianzishe nakala ya mwingiliano kando ya mahali pa kuingia panaposimamia handaki hilo tayari, kwa sababu michakato miwili itapigana juu ya kifaa na njia. Mchakato mdogo wa init ndani ya kontena hukusanya watoto na kupeleka ishara; haugeuzi picha kuwa mwenyeji wenye unit.
Ikiwa usambazaji unahitaji systemd ndani ya kontena kwa kweli, unahitaji picha iliyoundwa kwa makusudi kwa hilo, si ruhusa za ziada zinazoongezwa hadi systemctl itakapoacha kulalamika.
Soma hitilafu inayofuata pale meneja anapokuwepo
Mara tu meneja halisi anapoanzisha huduma, hitilafu zenye manufaa huanza. Kushindwa kwa ruhusa ya kifaa, hitilafu ya uchanganuzi wa usanidi, vitambulisho vinavyokosekana na mwenzake asiyefikiwa ni matatizo manne tofauti ambayo ujumbe wa PID 1 haukuwa ukijaribu kamwe. Soma kwa mpangilio ambao unit iliyazalisha, ukitumia journalctl -u openvpn-client@office -n 50 kwenye mwenyeji wa systemd, au kwa kuendesha mteja mbele mahali pasipo meneja. Kuendesha mbele pia ni njia ya haraka zaidi ya kuthibitisha kwamba wasifu wenyewe unafanya kazi.
Tenganisha mazingira mawili kwenye madokezo yako: mwenyeji unaoendesha handaki, na mahali unapoandika amri.