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

चाहे कुछ भी चुनें, कुछ भी दोबारा चलाने से पहले दर्ज परिणाम जाँचें। आखिरी पंक्ति का गायब होना बताता है कि लैपटॉप ने क्या देखा, यह नहीं कि सर्वर ने क्या कमिट किया। यही अंतर शुरू से ही काम को कनेक्शन से बाहर रखने की वजह है, और डिटैच और रीअटैच मॉडल इसका सबसे छोटा रूप है।