VPN सोबत SSH सत्र मरते: tmux की जॉब रनर?
पुन्हा जोडलेली टनेल जुने SSH सॉकेट जिवंत करत नाही। कामाला पुन्हा जोडायचे टर्मिनल सत्र हवे की नोंदवलेल्या निकालासह जॉब, हे ठरवा।
तुमचा VPN निर्देशक हिरवा होतो, मार्ग परत येतो, आणि तुम्ही उघडी सोडलेली SSH विंडो कधीही प्रॉम्प्ट परत देत नाही। मार्ग पुनर्संचयित केल्याने तो वापरणारे TCP संभाषण पुनर्संचयित होत नाही, त्यामुळे त्या विंडोमध्ये टाइप केलेले सर्व गेले। खरी चिंता संपादकाचा बफर किंवा लांब मायग्रेशन असेल, तर उपाय म्हणजे ते काम एका कनेक्शनला बांधणे थांबवणे। tmux आणि जॉब रनर त्या समस्येचे वेगवेगळे अर्धे भाग सोडवतात।
पुन्हा जोडलेला VPN सॉकेट पुढे चालू ठेवत नाही
पत्ता बदलल्यानंतर पुढे चालू ठेवण्याची कल्पना TCP मध्ये नाही। SSH कनेक्शन दोन्ही टोकांनी ओळखले जाते, आणि टनेल पुन्हा बांधले जाते तेव्हा स्थानिक पत्ता बदलू शकतो आणि जुने सॉकेट मृत होते। सर्व्हरला ते शेवटी कळते, पण तुमच्या टर्मिनलला ते लगेच कळते।
क्लायंट कीपअलाइव्ह मृत साथीदाराला लवकर ओळखतो। ते सत्र परत आणत नाही, आणि आधीच चालू असलेली आज्ञा पुनर्प्राप्त करू शकत नाही। कीपअलाइव्ह हा शोधक आहे, पुनर्प्राप्तीचे साधन नाही। दूरची आज्ञा टिकली की नाही याबद्दल ते काहीही सांगत नाही।
काम दूरच्या होस्टवर ठेवा
सत्र लॅपटॉपवर नाही, दूरच्या होस्टवर तयार करा। नेहमीप्रमाणे जोडा, तिथे tmux सुरू करा, आणि त्याच्या आत संपादक किंवा मायग्रेशन चालवा। डीफॉल्ट प्रीफिक्सने डिटॅच करा आणि SSH कनेक्शन गेले तरी सत्र चालू राहते। स्थानिक पातळीवर tmux सुरू करणे तुमच्या शेलला बंद विंडोपासून वाचवते, दूरच्या आज्ञेला मृत टनेलपासून नाही।
ssh [email protected]
tmux new-session -s office-workVPN परत आल्यावर त्याच होस्टवर नवीन SSH कनेक्शन उघडा आणि नावाने पुन्हा जोडा। टिकाऊ वस्तू सत्र आहे, कनेक्शन नाही। अस नाव द्या जे तुम्ही आठवड्यानंतरही ओळखाल।
tmux विरुद्ध जॉब रनर
होस्ट चालू असेपर्यंत tmux इंटरॅक्टिव्ह प्रक्रिया जिवंत ठेवतो। जॉब रनर किंवा सेवा व्यवस्थापक इंटरॅक्टिव्ह नसलेली जॉब जिवंत ठेवतो, तिची एक्झिट स्थिती नोंदवतो, आणि SSH सत्र पूर्णपणे संपले तरी टिकतो। पहिला तुम्ही पाहत असलेल्या कामासाठी आहे; दुसरा तुम्ही नियोजित करून नंतर तपासता त्या कामासाठी।
होस्ट पुनर्संचयित करण्यासाठी कॉन्फिगर केलेला नसेल तर दोन्हीपैकी कोणतेही रीबूटमध्ये टिकत नाही। tmux सत्र मशीनसोबत मरते, आणि तात्पुरती जॉब युनिट म्हणून नोंदवली नसेल तर बूटसोबत मरते। कामाला कशापुढे टिकायचे आहे त्यानुसार निवडा।
दोन्ही पद्धतींना पुन्हा जोडल्यावर वाचता येईल असा लॉगही हवा। तो नसेल तर प्रक्रिया आहे हे कळते, पण तिने काय केले ते नाही। लॉगचा मार्ग सत्राच्या नावाजवळ लिहून ठेवा।
काय टिकले पाहिजे यावरून ठरवा
काम अर्ध्यात थांबल्यास होऊ शकणाऱ्या सर्वात वाईट गोष्टीवरून ठरवा। संपादक सत्र न साठवलेले बफर गमावते, जे त्रासदायक पण पुनर्प्राप्त करण्यायोग्य आहे। आपल्या अर्ध्या बदलांची नोंद करणारे मायग्रेशन तसे नाही, आणि त्यामुळे नोंदवलेल्या निकालासह रनरच्या बाजूने युक्तिवाद होतो। जॉब इंटरॅक्टिव्ह आणि लांब असेल तर tmux आणि लिखित लॉग सहसा पुरतो।
systemd-run --user --unit=migrate-customers --collect ./migrate.shकाहीही निवडा, काहीही पुन्हा चालवण्यापूर्वी नोंदवलेला निकाल तपासा। शेवटची ओळ नसणे म्हणजे लॅपटॉपने काय पाहिले हे सांगते, सर्व्हरने काय नोंदवले ते नाही। हाच फरक काम सुरुवातीपासून कनेक्शनबाहेर ठेवण्याचे कारण आहे, आणि डिटॅच आणि पुन्हा अटॅच मॉडेल हे त्याचे सर्वात लहान रूप आहे।