SSH նստաշրջանը մահանում է VPN-ի հետ. tmux, թե աշխատանքների գործարկիչ:
Վերամիացված թունելը չի վերակենդանացնում հին SSH socket-ը: Որոշեք՝ աշխատանքին պետք է տերմինալային նստաշրջան, որին նորից միանում եք, թե գրանցված արդյունքով աշխատանք:
Ձեր VPN ցուցիչը կանաչում է, երթուղին վերադառնում է, և այն SSH պատուհանը, որը բաց էիք թողել, այլևս երբեք հուշում չի վերադարձնում։ Երթուղու վերականգնումը չի վերականգնում այն TCP զրույցը, որն օգտագործում էր այն, ուստի այդ պատուհանում մուտքագրված ամեն ինչ կորել է։ Եթե իրական մտահոգությունը խմբագրիչի բուֆերն է կամ երկար միգրացիան, լուծումը այդ աշխատանքը մեկ միացությանը կապելը դադարեցնելն է։ tmux-ը և աշխատանքների գործարկիչը լուծում են այդ խնդրի տարբեր կեսերը։
Վերամիացված VPN-ը չի շարունակում socket-ը
TCP-ն պատկերացում չունի հասցեի փոփոխությունից հետո շարունակելու մասին։ SSH միացությունը նույնացվում է երկու ծայրերով, և երբ թունելը նորից կառուցվում է, տեղական հասցեն կարող է փոխվել, և հին socket-ը մահացած է։ Սերվերը դա նկատում է ի վերջո, բայց ձեր տերմինալը նկատում է անմիջապես։
Հաճախորդի keepalive ավելի վաղ է հայտնաբերում մահացած գործընկերոջը։ Այն չի վերադարձնում նստաշրջանը և չի կարող վերականգնել արդեն աշխատող հրամանը։ keepalive-ը հայտնաբերիչ է, ոչ թե վերականգնման գործիք։ Այն ոչինչ չի ասում այն մասին, թե արդյոք հեռավոր հրամանը ողջ է մնացել։
Աշխատանքը դրեք հեռավոր հոսթի վրա
Ստեղծեք նստաշրջանը հեռավոր հոսթի վրա, ոչ թե նոութբուքի։ Միացեք ինչպես սովորաբար, այնտեղ միացրեք tmux-ը և դրա ներսում գործարկեք խմբագրիչը կամ միգրացիան։ Անջատվեք լռելյայն նախածանցով, և նստաշրջանը շարունակում է աշխատել, մինչ SSH միացությունը անհետանում է։ tmux-ը տեղային գործարկելը պաշտպանում է ձեր shell-ը փակ պատուհանից, ոչ թե հեռավոր հրամանը մահացած թունելից։
ssh [email protected]
tmux new-session -s office-workԵրբ VPN-ը վերադառնա, բացեք նոր SSH միացություն նույն հոսթին և նորից միացեք անունով։ Կայուն օբյեկտը նստաշրջանն է, ոչ թե միացությունը։ Տվեք այնպիսի անուն, որը կճանաչեք նաև մեկ շաբաթ անց։
tmux-ը ընդդեմ աշխատանքների գործարկիչի
tmux-ը կենդանի է պահում ինտերակտիվ գործընթացը, քանի դեռ հոսթը միացված է։ Աշխատանքների գործարկիչը կամ ծառայությունների կառավարիչը կենդանի է պահում ոչ ինտերակտիվ աշխատանքը, գրանցում է դրա ելքի կարգավիճակը և վերապրում է SSH նստաշրջանի ամբողջական ավարտը։ Առաջինը ձեր դիտարկած աշխատանքի համար է, երկրորդը՝ պլանավորված և ավելի ուշ ստուգվող աշխատանքի։
Ոչ մեկը չի վերապրում վերագործարկումը, եթե հոսթը կարգավորված չէ այն վերականգնելու համար։ tmux նստաշրջանը մահանում է մեքենայի հետ, և ժամանակավոր աշխատանքը մահանում է բեռնման հետ, եթե այն միավոր չի գրանցվել։ Ընտրեք ըստ այն բանի, ինչը աշխատանքը պետք է վերապրի։
Երկու մոտեցումներն էլ պահանջում են մատյան, որը կարող եք կարդալ վերամիացումից հետո։ Առանց դրա դուք գիտեք, որ գործընթացը գոյություն ունի, բայց ոչ այն, ինչ նա արել է։ Գրանցեք մատյանի ուղին նստաշրջանի անվան կողքին։
Որոշեք ըստ այն բանի, ինչը պետք է վերապրի
Որոշեք ըստ ամենավատի, ինչը կարող է պատահել, եթե աշխատանքը կիսաճանապարհին կանգնի։ Խմբագրիչի նստաշրջանը կորցնում է չպահված բուֆերները, ինչը նյարդայնացնում է, բայց վերականգնելի է։ Միգրացիան, որը հաստատում է իր փոփոխությունների կեսը, այդպիսին չէ, և դա նպաստում է գրանցված արդյունքով գործարկիչին։ Եթե աշխատանքը ինտերակտիվ է և երկար, tmux-ը գումարած գրավոր մատյանը սովորաբար բավարար է։
systemd-run --user --unit=migrate-customers --collect ./migrate.shԻնչ էլ ընտրեք, նախքան որևէ բան նորից գործարկելը ստուգեք գրանցված արդյունքը։ Բացակայող վերջին տողը ձեզ ասում է, թե ինչ տեսավ նոութբուքը, ոչ թե ինչ հաստատեց սերվերը։ Հենց այդ տարբերությունն է պատճառը աշխատանքը սկզբից միացությունից դուրս պահելու, և անջատման և նորից միացման մոդելը դրա ամենափոքր տարբերակն է։