SSH पर vim फ़्रीज़ हो रहा है? VPN को दोष देने से पहले stty जाँचें

ऐसे सत्र संपादक के शुरू होते समय जुड़े रहते हैं, फिर स्क्रीन अपडेट होना बंद कर देती है, हालाँकि SSH प्रक्रिया स्पष्ट रूप से जीवित है। टाइप करने से कुछ नहीं आता, Ctrl-C कुछ नहीं करता दिखता है, और स्पष्ट निष्कर्ष यह है कि VPN ने कुछ गिरा दिया। ज़्यादातर समय सुरंग ठीक होती है और दूरस्थ स्यूडो-टर्मिनल ऐसी स्थिति में होता है जिसका किसी ने इरादा नहीं किया, क्योंकि इको, कैनोनिकल इनपुट और फ़्लो नियंत्रण नेटवर्क में नहीं, टर्मिनल में रहते हैं। इन तीनों में से कौन हिला, यह पता करना दो कमांड का काम है।

जमाव सुरंग में नहीं, टर्मिनल में रहता है

स्यूडो-टर्मिनल बाइट्स से अधिक ढोता है। यह लाइन-अनुशासन फ़्लैग रखता है जो तय करते हैं कि इनपुट प्रतिबिंबित होता है या नहीं, पढ़ाई नई पंक्ति की प्रतीक्षा करती है या नहीं, कुछ अक्षर सिग्नल बनाते हैं या नहीं, और नियंत्रण अक्षर से आउटपुट रोका जा सकता है या नहीं। इंटरैक्टिव संपादक उस टर्मिनल को पूरे समय के लिए कच्चे मोड में डालता है और बाहर निकलते समय पिछली सेटिंग्स बहाल करने की अपेक्षा होती है। जब बहाली नहीं होती, तो आप जिस शेल में लौटते हैं वह वह शेल नहीं है जिसे आपने छोड़ा था, भले ही कनेक्शन कभी टूटा न हो।

कुछ भी निष्कर्ष निकालने से पहले टर्मिनलों की तुलना करें। वही संपादक चलाने वाला दूसरा सत्र साबित करता है कि क्लाइंट और मार्ग काम कर सकते हैं; यह उस टर्मिनल के बारे में कुछ नहीं कहता जिसके फ़्लैग टूटे हैं।

जिस टर्मिनल पर जमाव आया उस पर सेटिंग्स पढ़ें

पहले डिवाइस पहचानें, फिर उसकी स्थिति के दोनों रूप पढ़ें। पठनीय रूप दिखाता है कि क्या सेट है, और मशीन रूप वह है जिसे आप बाद में वापस फ़ीड कर सकते हैं।

tty
stty -a
stty -g

तीन फ़्लैग समूह इनमें से अधिकांश रिपोर्ट समझाते हैं। इको सेटिंग्स तय करती हैं कि कीस्ट्रोक बिलकुल दिखते हैं या नहीं, इसलिए इको बंद टर्मिनल मृत दिखता है जबकि शेल हर अक्षर प्राप्त कर रहा होता है। कैनोनिकल मोड तय करता है कि प्रोग्राम इनपुट एक बार में एक पंक्ति देखता है या नहीं, इसलिए कैनोनिकल मोड में छोड़ा गया टर्मिनल कच्चे मोड के अनुप्रयोग को Enter तक कुंजियों को अनदेखा करता हुआ दिखाता है। फ़्लो-नियंत्रण सेटिंग्स तय करती हैं कि टर्मिनल XON और XOFF अक्षरों का पालन करता है या नहीं, और यही समूह तीनों में सबसे विश्वसनीय नकली जमाव पैदा करता है।

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

उसी टर्मिनल को ठीक करें, जिस सत्र में आप टाइप कर रहे हैं उसे नहीं

मानक मरम्मत मैन पेज में सूचीबद्ध स्वस्थ प्रोफ़ाइल बहाल करती है, और यह केवल एक टर्मिनल को प्रभावित करती है। यदि संपादक अभी भी उस टर्मिनल में असहेजा कार्य रखता है, तो कार्य सहेजे जाने तक उसे अकेला छोड़ दें।

किसी अन्य शेल से, जमे हुए डिवाइस को स्पष्ट रूप से लक्षित करें ताकि आप जिस टर्मिनल में काम कर रहे हैं वह अछूता रहे।

stty -F /dev/pts/7 -a
stty -F /dev/pts/7 sane

भ्रष्ट प्रदर्शन वाली खाली स्क्रीन टूटे लाइन-अनुशासन से अलग समस्या है, और reset प्रोग्राम टर्मिनल आरंभीकरण अनुक्रम भेजकर उसे संबोधित करता है। पहले स्थिति मरम्मत आज़माएँ, क्योंकि यह ऐसी सेटिंग्स बदलती है जिन्हें आप निरीक्षण कर सकते हैं, जबकि reset अनुक्रम स्क्रीन को फिर से लिखता है और यह नहीं बताता कि यह कैसे टूटा।

विश्वसनीय जमाव के पीछे Ctrl-S जाल

जब सॉफ़्टवेयर फ़्लो नियंत्रण सक्षम हो और सामान्य अक्षर आवंटित हों, Ctrl-S टर्मिनल से आउटपुट भेजना बंद करने को कहता है और Ctrl-Q फिर शुरू करने को कहता है। सत्र पूरे समय जीवित रहता है, एक ही Ctrl-Q अक्सर पूरी मरम्मत होती है, और किसी लॉग में कुछ नहीं दिखता, और इसी तरह यह जमाव इतने सारे उन्नयनों से बच जाता है।

मान लेने के बजाय वास्तविक सेटिंग्स का निरीक्षण करें। आरंभ और रोक अक्षरों को पुनः आवंटित या अक्षम किया जा सकता है, और फ़्लो नियंत्रण बंद टर्मिनल दोनों में से किसी पर प्रतिक्रिया नहीं देगा।

यदि स्थिति लौटती है, या SSH स्वयं अटकता है

बार-बार आने वाली खराब स्थिति ऐसी किसी चीज़ की ओर इशारा करती है जो फ़्लैग बदलती है पर बहाल नहीं करती: स्टार्टअप फ़ाइल, रैपर स्क्रिप्ट, गलत विंडो रीसेट करने वाला मल्टीप्लेक्सर, या कच्चे मोड को पकड़े रहते मरने वाला अनुप्रयोग। बिना शर्त रीसेट के बजाय स्थिति की रिपोर्ट करने वाली सशर्त जाँच जोड़ें, क्योंकि व्यापक रीसेट कारण छिपाता है और जानबूझकर की गई सेटिंग्स को अधिलंघित कर सकता है।

जब सामान्य SSH ट्रैफ़िक भी अटकता है, या मरम्मत कुछ नहीं बदलती, टर्मिनल संदिग्ध रहना बंद कर देता है।

ssh -vvv [email protected]
ping -M do -s 1400 -c 3 host.example.com

केवल बड़े स्थानांतरणों के दौरान दिखने वाला अटकाव मार्ग की MTU समस्या का संकेत देता है, जबकि अकेले कीस्ट्रोक भी निगलने वाला अटकाव पैकेट के आकार पर नहीं, मार्ग या सर्वर की ओर इशारा करता है। टर्मिनल के साक्ष्य को नेटवर्क के साक्ष्य से अलग रखें, क्योंकि दूसरे सत्र में काम करता संपादक इस बात का प्रमाण नहीं है कि पहला टर्मिनल कभी स्वस्थ था।