systemd-ն դադարեցնում է VPN ծառայությունը. համապատասխանեցրեք Type= պարամետրը հաճախորդին

Միավորները կարող են ճիշտ թվալ, systemctl start-ը կարող է հաջողություն հաղորդել, և տասը վայրկյան անց ծառայությունը մնում է ոչ ակտիվ։ Կամ այն վերագործարկվում է ամեն կես րոպեն, մինչև մեկնարկի սահմանը կանգնեցնի այն։ Վարքագծերից ոչ մեկը ցանցի խափանում չէ. միավորը նկարագրում է գործընթացի կյանք, որը չի համապատասխանում այն բանին, ինչ հաճախորդն իրականում անում է։ Հաճախորդը կարող է fork անել և դուրս գալ, կամ կարգավորել նստաշրջանը և անմիջապես դուրս գալ։

Ինչու է միավորը ոչ ակտիվ դառնում հաջող մեկնարկից վայրկյաններ անց

systemd-ն վիճակը եզրակացնում է այն գործընթացից, որը ինքն է սկսել, ուստի Type=-ը պնդում է այդ գործընթացի մասին, ոչ թե փաստաթղթեր։ Type=simple-ի դեպքում միավորը ակտիվ է համարվում, քանի դեռ հրամանը աշխատում է, և ոչ ակտիվ է դառնում, երբ այն վերադառնում է։ Այն հաճախորդը, որը կապը հանձնում է օժանդակ ծրագրի և դուրս է գալիս, դրա համար վթարի տեսք ունի, նույնիսկ երբ թունելը աշխատում է։ Այնուհետև մատյանը ցույց է տալիս մեկնարկ-կանգ օրինաչափություն, որը կարդացվում է որպես անսարք բինար։

Կարդացեք միավորի տեսակը հաճախորդի վարքագծի կողքին, նախքան ցանցի կարգավորումներին դիպչելը։

Ընտրեք այն տեսակը, որը համապատասխանում է հաճախորդին

Երկու օրինաչափություն ընդգրկում են մատակարարների CLI-ների մեծ մասը. հրաման, որը կարգավորում է նստաշրջանը և դուրս գալիս, և հրաման, որը վերադարձից առաջ fork է անում օժանդակ ծրագիր։ Յուրաքանչյուրը պահանջում է միավորի այլ ձև։

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot-ը RemainAfterExit=true-ի հետ պահում է միավորը ակտիվ հրամանի վերադարձից հետո, ինչը համապատասխանում է կարգավորիր-ու-դուրս-եկ օրինաչափությանը, իսկ կանգի հրամանը ծառայությանը տալիս է մաքուր անջատում։ Fork անող հաճախորդը պահպանում է նույն ձևը, բայց կարիք ունի Type=forking-ի, որպեսզի systemd-ն հետևի զավակին։ Սահմանեք Restart=on-failure, RestartSec=30 և վերջավոր StartLimitBurst, որպեսզի մատակարարի ընդհատումը չվերածվի վերագործարկումների օղակի, որը թաղում է սխալը։

Երբեք թույլ մի տվեք, որ վերահսկվող հաճախորդը դեմոն դառնա

systemd-ից դուրս վերահսկիչները բախվում են նույն պատին։ runit-ի գործարկման սկրիպտը, որը միացնում է դեմոնացված հաճախորդ, անմիջապես վերադառնում է վերահսկիչին, և նա այդ վերադարձը կարդում է որպես վթար ու սկսում ևս մեկ օրինակ։ Յուրաքանչյուր վերահսկիչ ակնկալում է տիրել առաջին պլանի գործընթացին, ինչպես sshd -D-ը մնում է առջևում։ Հեռացրեք դեմոնի դրոշակը վերահսկվող հրամաններից և թողեք ֆոնային աշխատանքը վերահսկիչին։ Փաթաթող սկրիպտները, որոնք վերադառնում են մինչև թունելի գոյությունը, նույն շփոթությունն են առաջացնում։

Գործընթացը, որն իրենից անջատվում է, անտեսանելի է այն ամենի համար, ինչ պետք է հսկեր այն։

Նստաշրջանն ավարտվում է և իր հետ տանում թունելը

Սեղանի նստաշրջանը տիրում է իր գործարկած հաճախորդին։ Ավարտեք մուտքը, և նստաշրջանի ավտոբուսը անհետանում է՝ իր հետ տանելով թունելը, ինչը բացատրում է, թե ինչու գրաֆիկական հաճախորդի կապը հաճախ ընկնում է, երբ փակվում է վերջին պատուհանը։ Սերվերները պետք է օգտագործեն համակարգի միավոր կամ NetworkManager պրոֆիլ, որը ինքնուրույն բարձրանում է։ Օգտատիրոջ միավորը իմաստ ունի միայն այն դեպքում, երբ թունելը պետք է ավարտվի մուտքի հետ, ուստի կապեք այն գրաֆիկական նստաշրջանի թիրախին և նշեք դա նկարագրության մեջ։

Ծառայության օգտատերը նույն խնդրի մյուս կեսն է։ root-ին պատկանող և 0600 ռեժիմով բանալին անընթեռնելի է այլ հաշվով աշխատող միավորի համար, ինչ էլ որ sudo-ն հասել է ձեր shell-ում։

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

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

Երբ դեմոնը կապվում է թունելի հասցեին, որը դեռ չի ստեղծվել, այն դուրս է գալիս Cannot assign requested address հաղորդագրությամբ։ Ուղղումը բացահայտ հերթականությունն է, ոչ թե կրկնակի փորձերի օղակ։

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

After=-ը դասավորում է աշխատանքները, մինչդեռ սարքի միավորի Requires=-ը կախյալը կապում է ինտերֆեյսի գոյությանը, ինչն ավելի ուժեղ է, քան միայն ցանցի թիրախին սպասելը։ Խմբագրելուց հետո վերաբեռնեք կառավարիչը և վերագործարկեք կախյալ ծառայությունը, ապա կարդացեք դրա մատյանը՝ հերթականությունը գործել է ենթադրելու փոխարեն։ Ուղարկեք հաճախորդի ելքը մատյան StandardOutput=journal-ով կամ լոգի ընտրանքով, որովհետև վերահսկվող հաճախորդը, որը գրում է ֆայլ, որը ոչ ոք չի բացում, ճիշտ նույն տեսքն ունի, ինչ երբեք չմեկնարկածը։

Այնուհետև մեկ անգամ վերագործարկեք և հաստատեք, որ միավորը ակտիվ է թունելի սարքի հայտնվելուց հետո։ Միայն systemctl start-ով ստուգված ուղղումը չի փորձարկել այն մեկնարկային հերթականությունը, որը պետք է ուղղեր։