VPN सँगै SSH सत्र मर्छ: tmux कि जागिर रनर?

तपाईंको VPN सूचक हरियो हुन्छ, मार्ग फर्कन्छ, र तपाईंले खुला छाडेको SSH झ्यालले कहिल्यै प्रम्प्ट फर्काउँदैन। मार्ग पुनर्स्थापना गर्दा त्यसलाई प्रयोग गरिरहेको TCP वार्तालाप पुनर्स्थापना हुँदैन, त्यसैले त्यो झ्यालमा टाइप गरिएको सबै गयो। यदि साँचो चिन्ता सम्पादकको बफर वा लामो माइग्रेसन हो भने, समाधान त्यो कामलाई एउटै जडानमा बाँध्न छोड्नु हो। tmux र जागिर रनरले त्यो समस्याका फरक फरक आधा भाग समाधान गर्छन्।

पुनः जोडिएको VPN सकेटलाई निरन्तरता दिँदैन

ठेगाना परिवर्तनपछि फेरि सुरु गर्ने धारणा TCP मा छैन। SSH जडान दुवै छेउबाट पहिचान गरिन्छ, र टनेल फेरि निर्माण हुँदा स्थानीय ठेगाना बदलिन सक्छ र पुरानो सकेट मृत हुन्छ। सर्भरले त्यो अन्तमा थाहा पाउँछ, तर तपाईंको टर्मिनलले तुरुन्तै थाहा पाउँछ।

क्लाइन्ट किपअलाइभ मृत साथीलाई चाँडै पहिचान गर्छ। यसले सत्र फर्काउँदैन, र पहिले नै चलिरहेको आदेश पुनःप्राप्त गर्न सक्दैन। किपअलाइभ एक पहिचानकर्ता हो, पुनःप्राप्तिको साधन होइन। दूरको आदेश बाँच्यो कि भन्नेबारे यसले केही भन्दैन।

काम दूरको होस्टमा राख्नुहोस्

सत्र ल्यापटपमा होइन, दूरको होस्टमा सिर्जना गर्नुहोस्। सधैंझैं जोडिनुहोस्, त्यहाँ tmux सुरु गर्नुहोस्, र त्यसभित्र सम्पादक वा माइग्रेसन चलाउनुहोस्। पूर्वनिर्धारित प्रिफिक्सले डिट्याच गर्नुहोस् र SSH जडान गए पनि सत्र चलिरहन्छ। स्थानीय रूपमा tmux सुरु गर्नुले तपाईंको शेललाई बन्द झ्यालबाट बचाउँछ, दूरको आदेशलाई मृत टनेलबाट होइन।

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

जे छाने पनि, केही फेरि चलाउनुअघि दर्ता गरिएको नतिजा जाँच्नुहोस्। अन्तिम लाइन नहुनुले ल्यापटपले के देख्यो भन्ने बताउँछ, सर्भरले के कमिट गर्यो भन्ने होइन। यही भिन्नता काम सुरुदेखि नै जडानबाहिर राख्ने कारण हो, र डिट्याच र पुनः अट्याच मोडेल त्यसको सबैभन्दा सानो रूप हो।