apt purge-ը հեռացրել է VPN-ը, բայց ծառայությունը դեռ սկսվում է բեռնման ժամանակ

apt purge-ը հայտնում է, որ փաթեթը գնացել է, և այնուամենայնիվ ամեն մեկնարկի ժամանակ թունելը նորից բարձրանում է։ Journal-ը շարունակում է աճել, երթուղիները վերադառնում են, և մեքենան իրեն պահում է այնպես, կարծես ոչինչ չի հեռացվել։ Մատակարարի տեղադրիչը կարող է գրել ֆայլեր, որոնք փաթեթների կառավարիչը երբեք չի գրանցել, ուստի փաթեթը հեռացնելը և արտադրանքը հեռացնելը տարբեր աշխատանքներ են. Ստորև բերված runbook-ը բաժանում է երկու գրառումները և ավարտում հեռացումը դիտավորյալ։

Երկու տեղադրիչ, երկու տարբեր գրառում

Debian փաթեթները պահում են ֆայլերի ցանկ, և purge-ը ջնջում է ճիշտ այն, ինչ նշում է այդ ցանկը, գումարած փաթեթի կարգավորումը։ Shell տեղադրիչը կամ .run փաթեթը նման ցանկ չի պահում. այն գրում է ուր ուզում է, սովորաբար /opt, /usr/local և /etc/systemd/system պանակներում։ Այդ ուղիներից ոչ մեկը չի հայտնվում ոչ մի փաթեթի ֆայլերի ցանկում, ուստի dpkg-ն ոչ գիտի դրանց մասին, ոչ էլ հաղորդում է։ Վերջում մեկ ֆայլային համակարգում ունեք տեղադրման երկու սեփականատեր, և նրանցից միայն մեկն է հաշիվներ վարում։

Ջնջելուց առաջ հարցրեք dpkg-ին կոնկրետ ուղու մասին։ Այն ուղին, որը նա հրաժարվում է, ձերն է հեռացնելու համար, և նույն պատասխանն ասում է՝ արդյոք հետագա թարմացումը այն կվերադարձնի։

dpkg -S /etc/systemd/system/acmevpn.service
systemctl list-unit-files | grep -i acmevpn

unit-ը և նրա wants հղումը առանձին ֆայլեր են

Միացնելը տեղադրելուց առանձին գործողություն է։ unit-ը հայտարարում է թիրախային հարաբերություններ իր [Install] բաժնում, և systemctl enable-ը այդ հայտարարությունները վերածում է խորհրդանշական հղումների յուրաքանչյուր թիրախի .wants/ պանակում։ Այժմ կա երկու ուղի՝ unit-ի ֆայլը և հղումը, որը քաշում է այն բեռնման թիրախ։ Ջնջեք միայն ֆայլը, և հղումը ոչ մի տեղ ցույց չի տալիս, ինչը բեռնման ժամանակ բողոք է առաջացնում. ջնջեք միայն հղումը, և unit-ը մնում է անվանումով սկսելի։ Երկուսն էլ պետք է գնան։

Հեռացրեք դրանք հերթականությամբ և հետո վերաբեռնեք, որպեսզի systemd-ը դադարի հին սահմանումները հիշողության մեջ պահելուց։

systemctl disable --now acmevpn.service
systemctl show -p FragmentPath -p ExecStart acmevpn.service
sudo rm /etc/systemd/system/acmevpn.service
sudo rm /etc/systemd/system/multi-user.target.wants/acmevpn.service
systemctl daemon-reload

Կարդացեք FragmentPath-ը՝ տեղը ենթադրելու փոխարեն, քանի որ մատակարարը կարող է գրել /usr/lib/systemd/system կամ /lib/systemd/system պանակում, ոչ թե /etc-ում։ Սպասված պատճենը ջնջելը թողնում է գործողը աշխատող, և ուղղումը հաջող է թվում մինչև հաջորդ վերաբեռնումը։ Վերաբեռնումից հետո նորից թվարկեք unit-ների ֆայլերը և հաստատեք, որ անունն այլևս չի երևում։

Գտեք այն բինարը, որը կենդանի է պահում այս դասավորությունը

Միացված unit-ը շարունակում է սկսել դեյմոնը, անկախ նրանից՝ ինչ է կարծում փաթեթների տվյալների բազան։ Այդ գործընթացը կարող է վերադարձնել թունելը, նորից ավելացնել երթուղիներ կամ վերականգնել kill-switch կանոն, և վարքը գերբնական է թվում, մինչև չուսումնասիրեք դասավորությունը։ Հետևեք ExecStart ուղուն և ստուգեք՝ արդյոք բինարը դեռ այնտեղ է, քանի որ /opt-ի տակ թողնված գործարկվող ֆայլը այն ամենն է, ինչ դասավորությանը պետք է։ unit-ը ջնջելը կանգնեցնում է պլանավորված մեկնարկը. այն չի ջնջում ծրագիրը։

Պետության պանակներին վերաբերվեք նույն խնամքով։ Հաշվի թոքենները, գեներացված պրոֆիլները և քեշավորված սերվերների ցանկերը ապրում են /var/lib-ի տակ կամ տնային պանակում, և դրանք հավատարմագրեր են, ոչ թե դեն նետվող քեշ։ Հեռացրեք դրանք ծառայությունը կանգնեցնելուց հետո, դիտավորյալ, և նշեք՝ ինչ վերցրիք։

sudo ls -l /opt/acmevpn /usr/local/bin/acmevpn
sudo find /var/lib -maxdepth 2 -iname "*acme*"
systemctl is-enabled acmevpn.service

Ընտրեք բեռնման մեկ սեփականատեր և փորձարկեք այն

Երեք թեկնածու կարող են հավակնել բեռնմանը, և բոլոր երեքը տեղադրելը ստեղծում է մրցավազք, ոչ թե կրկնակի պաշտպանություն։ Սեղանի ավտոմատ մեկնարկի ֆայլը աշխատում է միայն ինչ-որ մեկի մուտքից հետո, systemd unit-ը աշխատում է ավելի վաղ, բայց պահանջում է առանց էկրանի աշխատող կլիենտ, իսկ cron @reboot գրառումը գործարկվում է ըստ ժամանակացույցի, որը կարող է սխալ լինել ցանցային կլիենտի համար։ Մատակարարի CLI-ն կարող է լրացուցիչ պահանջել սերվերի արգումենտ, քանի որ բեռնման պահին նախորդ սեսիա չկա շարունակելու համար։ Ընտրեք այն թեկնածուն, որը համապատասխանում է կլիենտի նույնականացման եղանակին, և մերժեք մյուսներին։

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

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

Գրեք, ինչ պետք է սպասի հաջորդ purge-ը

Ցանկացած ձեռքով հեռացումից հետո նշեք երկու փաստ՝ ո՞ր տեղադրիչն է ստեղծել դասավորությունը, և ո՞ր սեփականատերն է հիմա սկսում այն։ Այդ նշումը հաջորդ purge-ը դարձնում է անակնկալից ստուգաթերթի կետ, և այն ապրում է ավելի երկար, քան աշխատանքը կատարող մարդը։

Պահեք այն ծառայության կարգավորման կողքին, ոչ թե անձնական պանակում, և ամսաթիվ դրեք, քանի որ մատակարարի թարմացումը կարող է վերականգնել ձեր ջնջած unit-ը։ systemctl list-unit-files-ը այդ նշման հետ մի քանի ամիսը մեկ համեմատելը բռնում է վերականգնումը, քանի դեռ ուղղումը էժան է։