क्या ssh सत्र से चलने वाले प्रोग्राम कनेक्शन पर निर्भर करते हैं?

29

क्या एक प्रोग्राम जो एक ssh सत्र से चलाया जाता है, क्लाइंट के कनेक्शन पर निर्भर करता है? उदाहरण के लिए जब कनेक्शन वास्तव में धीमा है। तो क्या यह तब तक सक्रिय रूप से प्रतीक्षा करता है जब तक कि चीजें स्क्रीन पर मुद्रित नहीं होती हैं?

और अगर यह कनेक्शन पर निर्भर करता है, तो क्या यह उदाहरण के लिए स्क्रीन या बायोबू के साथ भी होता है ? चूंकि इन कार्यक्रमों को होस्ट से डिस्कनेक्ट करने के बाद भी चालू रखा जाता है।

नोट: मुझे केवल ये संबंधित प्रश्न मिले हैं:

ssh tty job-control

— agold
स्रोत

1

ध्यान दें कि यदि आपका कनेक्शन खो गया है तो सत्र समय समाप्त होने तक जारी रहेगा (जब तक कि उसका प्रिंट ऑपरेशन में अटक न जाए), लेकिन यदि आपका सत्र समाप्त हो जाता है, तो कार्यक्रम को शालीनतापूर्वक समाप्त कर दिया जाएगा।

— सेबब

26

प्रोग्राम का आउटपुट बफ़र्ड है, इसलिए यदि कनेक्शन धीमा है तो बफर बंद होने पर प्रोग्राम को रोक दिया जाएगा।

यदि आप उपयोग करते हैं screen, तो इसके साथ एक बफर भी है जो इसे कनेक्टेड सत्र में प्रयास करने और प्रदर्शित करने के लिए उपयोग करता है। लेकिन स्क्रीन सत्र से जुड़ा एक कार्यक्रम बंद नहीं किया जाएगा यदि screenदूरस्थ टर्मिनल को पर्याप्त तेजी से अपडेट नहीं किया जा सकता है। जैसे जब कोई कनेक्शन खो जाता है, तो प्रोग्राम screensतब तक बफर भरना जारी रखता है जब तक कि यह ओवरफ्लो (सबसे पुरानी जानकारी को बाहर न कर दे)। आप जो भी देख रहे हैं (और वापस स्क्रॉल कर सकते हैं) उस बफ़र में जो है (अभी भी) पर निर्भर करता है। screenप्रभावी रूप से अपने टर्मिनल (और अपने धीमे एसएसएच कनेक्शन) से अपने कार्यक्रम को डिस्कस करता है।

— Anthon
स्रोत

9

एक SSH कनेक्शन समय से पहले मर सकता है यदि अंतर्निहित TCP कनेक्शन RST ध्वज के साथ एक पैकेट प्राप्त करता है । ऐसा हो सकता है यदि एक पक्ष एक पैकेट भेजता है (जो एक आवधिक एसएसएच रखवाली जांच हो सकता है) लेकिन उचित समय पर एक टीसीपी पावती प्राप्त नहीं करता है, या यदि एक राउटर तय करता है कि कनेक्शन बहुत लंबा हो गया है, या यदि एक आईएसपी सिर्फ बुराई है।

यूनिक्स टर्मिनल मॉडल में, जब टर्मिनल कनेक्शन को गिरा दिया जाता है, टर्मिनल चालक शेल को एक एचयूपी सिग्नल भेजता है , जिसकी समाप्ति के कारण शेल में चलने वाली प्रक्रियाओं के लिए एक SUPUP भेजा जाता है।

से यूनिक्स प्रोग्रामर पूछे जाने वाले प्रश्न , आइटम 1.15:

SIGHUPएक संकेत है जिसका अर्थ है, कन्वेंशन द्वारा, "टर्मिनल लाइन को लटका दिया गया"। इसका माता-पिता की प्रक्रियाओं से कोई लेना-देना नहीं है, और आमतौर पर ट्टी ड्राइवर (और अग्रभूमि प्रक्रिया समूह को दिया जाता है) द्वारा उत्पन्न होता है।

हालांकि, सत्र प्रबंधन प्रणाली के भाग के रूप में, वास्तव में दो मामले हैं जहां SIGHUPएक प्रक्रिया की मृत्यु पर भेजा जाता है:

जब मरने वाली प्रक्रिया एक सत्र का सत्र नेता है जो एक टर्मिनल डिवाइस से जुड़ा होता है, SIGHUPतो उस टर्मिनल डिवाइस के अग्रभूमि प्रक्रिया समूह में सभी प्रक्रियाओं के लिए भेजा जाता है।

जब एक प्रक्रिया के मौत का कारण बनता है एक प्रक्रिया समूह अनाथ को हो जाते हैं, और अनाथ समूह में एक या अधिक प्रक्रियाओं कर रहे हैं बंद कर दिया है, तो SIGHUPऔर SIGCONTअनाथ समूह के सभी सदस्यों के लिए भेजा जाता है। (एक अनाथ प्रक्रिया समूह वह है जहां समूह में किसी भी प्रक्रिया में कोई अभिभावक नहीं होता है जो समान सत्र का हिस्सा है, लेकिन समान प्रक्रिया समूह नहीं है।)

SIGHUP के लिए डिफ़ॉल्ट संकेत हैंडलर प्रक्रिया समाप्त करने के लिए है:

Signal     Value     Action   Comment
----------------------------------------------------------------------
SIGHUP        1       Term    Hangup detected on controlling terminal
                              or death of controlling process

हालांकि प्रक्रिया समाप्ति से बचना संभव है।

आप एक संकेत हैंडलर सम्मिलित कर सकते हैं जो SIGHUP की उपेक्षा करता है। एक उपयोगकर्ता के रूप में ऐसा करने के लिए, कमांड को अंदर लपेटें nohup। उदाहरण के लिए:
```
nohup make all &
```
आप एक बच्चे की प्रक्रिया को अलग करने के लिए शेल को बता सकते हैं। उदाहरण के लिए, बैश में एक disownअंतर्निहित कमांड है:
```
make all
```
CtrlZ
```
bg
disown %1
```
फिर, SIGHUP बच्चे को प्रचारित नहीं किया जाएगा (जो अब बच्चा नहीं है)।
कुछ प्रोग्राम, विशेष रूप से डेमॉन , स्वचालित रूप से ऊपर के तंत्र का उपयोग करेंगे: एक प्रोग्राम एक वैकल्पिक SightUP हैंडलर (उपयोग कर sigaction(2)) स्थापित कर सकता है, या यह एक नए सत्र में शामिल होने के लिए चुन सकता है ( setsid(2))।
आप चला सकते हैं screenया tmux, जो एक छद्म-टीटीवाई को एक शेल के साथ एक सत्र चलाने के लिए आवंटित करता है जो SSH कनेक्शन के मरने पर SIGHUP प्राप्त नहीं करता है। SIGHUP SSH सत्र से स्क्रीन / tmux सत्र से संबंधित नहीं है।

संयोग से, अविश्वसनीय एसएसएच कनेक्शन से निपटने का एक वैकल्पिक तरीका इसके बजाय मोश प्रोटोकॉल का उपयोग करना है। एमओपी यूडीपी पर चलता है, इसलिए कोई टीसीपी कनेक्शन नहीं है जो जोखिम को रीसेट करता है।

— 200_success
स्रोत

आगे पढ़ें: nohup, अस्वीकार और और के बीच अंतर ।

— 200_सफल

1

हां, SSH के ऊपर चलने वाला एक कार्यक्रम कहीं न कहीं इसके आउटपुट पर निर्भर करेगा। यदि कनेक्शन धीमा है, तो आउटपुट कहीं बफ़र किया जाना चाहिए, और बफ़र्स अनंत नहीं हो सकते हैं, इसलिए यदि वे भरे हुए हैं तो प्रोग्राम को ब्लॉक करना होगा।

ध्यान दें कि आउटपुट आवश्यक रूप से एक टर्मिनल पर नहीं जा सकता है: जैसे कुछ चलाने पर विचार करें

ssh user@somewhere "cat file.txt" > file.txt

यह प्रभावी रूप से फाइल की नकल करेगा। यह काम करने के लिए, बिल्ली का आउटपुट दर कनेक्शन से मेल खाना चाहिए: यह स्पष्ट होना चाहिए कि आउटपुट के कुछ हिस्सों को बीच से खोना अस्वीकार्य होगा।

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

आदमी पृष्ठ से:

नॉनब्लॉक [पर | बंद | अंकतालिका]

स्क्रीन को बताएं कि उपयोगकर्ता इंटरफ़ेस (डिस्प्ले) से कैसे निपटें जो आउटपुट को स्वीकार नहीं करता है। यह तब हो सकता है जब कोई उपयोगकर्ता ^ S या TCP / मॉडेम कनेक्शन को दबाता है, लेकिन कोई हैंगअप प्राप्त नहीं होता है। यदि नॉनब्लॉक बंद है (यह डिफ़ॉल्ट है) स्क्रीन तब तक इंतजार करती है जब तक कि डिस्प्ले आउटपुट को स्वीकार करने के लिए पुनरारंभ नहीं होता है। यदि नॉनब्लॉक चालू है, तो स्क्रीन आउट होने तक प्रतीक्षा करता है (ऑन 1s के रूप में माना जाता है)। यदि प्रदर्शन अभी भी वर्ण प्राप्त नहीं करता है, तो स्क्रीन इसे "अवरुद्ध" मान लेगी और पात्रों को भेजना बंद कर देगी। यदि किसी समय यह वर्णों को स्वीकार करने के लिए पुनरारंभ होता है, तो स्क्रीन डिस्प्ले को अनब्लॉक करेगा और अपडेट की गई विंडो सामग्री को फिर से परिभाषित करेगा।

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

( nonblock 1आपके .screenrcलिए सेटिंग महत्वपूर्ण है यदि आप irssi जैसी कोई चीज़ चलाते हैं जो लगातार आउटपुट का उत्पादन करेगी लेकिन फिर भी उसी समय नेटवर्क से बात करनी चाहिए। ब्लॉकिंग से IRC से डिस्कनेक्ट हो जाएगा, जो कि बहुत कष्टप्रद है ...)

— ilkkachu
स्रोत