Երբ systemctl start openvpn-client@office գործարկելիս ստանում եք հաղորդագրություն, որ համակարգը systemd-ով չի բեռնվել, դա թվում է ծառայության ձախողում։ Դա բոլորովին էլ ծառայության ձախողում չէ. systemctl-ը, որ կանչել եք, չի գտնում աշխատող կառավարիչ, որի հետ խոսի, ուստի OpenVPN-ի մասին ոչինչ չի ստուգվել։ sudo կառավարիչ չի ստեղծում, և unit ֆայլի տեղադրումը նույնպես այն չի ստեղծում։ Հրամանն ու մեքենան գալիս են երկու տարբեր աշխարհներից, և սխալը միակ տեղն է, որտեղ դա երևաց։

Սկսեք հարցից, թե որ գործընթացն է տիրապետում PID 1-ին այնտեղ, որտեղ գործարկվում է հրամանը, քանի որ այդ պատասխանը որոշում է՝ unit-ներ ընդհանրապես կա՞ն։

Սխալը նշում է միջավայրը, ոչ թե OpenVPN-ը

systemctl հաճախորդ է, ոչ թե կառավարիչ։ Այն միանում է համակարգի կառավարչին socket-ի միջոցով, և երբ մյուս ծայրում կառավարիչ չկա, տպում է այն հաղորդագրությունը, որը մարդիկ տեղադրում են ֆորումներում։ ps -p 1 -o pid=,comm= ցույց է տալիս, թե ինչ է իրականում աշխատում որպես PID 1, և պատասխանը հաճախ shell-ն է, init-փաթաթան կամ բուն կոնտեյների մուտքային կետը։ Նման իրավիճակում unit ֆայլը կարող է լիովին վավեր լինել և այդուամենայնիվ երբեք չկարդացվել։ Հրամանը root-ով կրկնելը փոխում է միայն հաճախորդի հավատարմագրերը։

Կարդացեք ամբողջ հաղորդագրությունը առաջին տողից առաջ։ Կառավարչից եկող սխալը, օրինակ բացակայող unit կամ ձախողված պայման, նշանակում է, որ հասել եք դրան. այս սխալը նշանակում է, որ չեք հասել։

WSL. systemd-ի միացումը կոնֆիգուրացիայի փոփոխություն է

WSL-ը systemd-ի աջակցություն ստացավ ավելի ուշ թողարկումներում, սակայն ֆունկցիան միացվում է յուրաքանչյուր տարածման համար առանձին և միայն այնտեղ, որտեղ տեղադրված WSL տարբերակն աջակցում է այն։ wsl --version Windows-ի կողմում ցույց է տալիս, թե ինչ ունեք, իսկ տարածման /etc/wsl.conf ֆայլը պարունակում է [boot] բաժին՝ systemd=true-ով։ Խմբագրեք այդ ֆայլը՝ չհեռացնելով արդեն առկա բաժինները, ապա վերագործարկեք WSL-ի օրինակը, որպեսզի փոփոխությունն ուժի մեջ մտնի։ wsl --shutdown դադարեցնում է բոլոր աշխատող տարածումները, ուստի նախ պահպանեք ձեր աշխատանքը։

Վերաբացելուց հետո հաստատեք կառավարիչը՝ նախքան OpenVPN-ի unit-ին դիպչելը. ps -p 1 -o comm= պետք է ցույց տա systemd։ systemd-ի միացումը չի տալիս պրոֆիլ, հավատարմագրեր կամ օրինակի անուն, ուստի հաջորդ սխալը կվերաբերի դրանցից մեկին, ոչ թե PID 1-ին։

Կոնտեյներները գործարկում են իրենց մուտքային կետը, ոչ թե unit-ները

Սովորական կոնտեյները գործարկում է այն, ինչ սահմանում է իր մուտքային կետը կամ հրամանը, և այն systemd-ով բեռնված մեքենա չէ, ինչ փաթեթներ էլ տեղադրեք։ Եթե systemctl-ը ավելացնեք պատկերին, կստանաք հաճախորդ, որին միանալու բան չկա։ Community OpenVPN-ի համար աջակցվող ձևը սովորաբար առաջին պլանում աշխատող գործընթացն է՝ openvpn --config /path/to/client.conf, որը գործարկվում է մուտքային կետի կողմից և վերահսկվում դրսից։ Այդ սեփականատերը զբաղվում է մեկնարկով, ազդանշաններով և անջատմամբ, և հենց նա պետք է լինի միակը, որը կառավարում է թունելը։

Երբեք ինտերակտիվ պատճեն մի գործարկեք այն մուտքային կետի կողքին, որն արդեն կառավարում է այդ թունելը, որովհետև երկու գործընթաց կկռվեն սարքի և երթուղիների համար։ Նվազագույն init գործընթացը կոնտեյների ներսում հավաքում է զավակներին և փոխանցում ազդանշանները. այն պատկերը չի դարձնում unit-ներով հոսթ։

Եթե տեղաբաշխումն իսկապես systemd է պահանջում կոնտեյների ներսում, նրան պետք է դիտավորյալ նախագծված պատկեր, ոչ թե լրացուցիչ արտոնություններ, որոնք ավելացվում են այնքան ժամանակ, քանի դեռ systemctl չի դադարի բողոքել։

Կարդացեք հաջորդ սխալը, երբ կառավարիչը գոյություն ունի

Հենց իրական կառավարիչը գործարկում է ծառայությունը, սկսվում են օգտակար սխալները։ Սարքի թույլտվության ձախողում, կոնֆիգուրացիայի վերլուծության սխալ, բացակայող հավատարմագրեր և անհասանելի գործընկեր՝ դրանք չորս տարբեր խնդիրներ են, որոնք PID 1-ի հաղորդագրությունը երբեք չի ստուգել։ Կարդացեք դրանք այն հերթականությամբ, որով unit-ը ստեղծել է դրանք՝ օգտագործելով journalctl -u openvpn-client@office -n 50-ը systemd հոսթում, կամ հաճախորդը առաջին պլանում գործարկելով այնտեղ, որտեղ կառավարիչ չկա։ Առաջին պլանում գործարկելը նաև ամենաարագ ձևն է հաստատելու, որ պրոֆիլն ինքն է աշխատում։

Ձեր գրառումներում առանձին պահեք երկու միջավայրերը՝ թունելը գործարկող հոսթը և այն տեղը, որտեղ մուտքագրում եք հրամանները։

Առնչվող հոդվածներ