सवाल एसएसएच सत्र से डिस्कनेक्ट हो रहा है अपने कार्यक्रमों को मार डालो?


तो, कहें कि मैंने शुरू करने के बाद एसएसएच-सत्र से डिस्कनेक्ट किया है rsync या cp या कोई अन्य आदेश जो लंबे समय तक चल सकता है। क्या यह आदेश तब तक चल रहा है जब तक कि यह डिस्कनेक्ट हो जाने के बाद खत्म हो जाता है या क्या यह सिर्फ मारे जाते हैं?

हमेशा यह सोच लिया।


75
2018-01-06 03:09


मूल


मैं बस ऊपर जो कहा गया है उसे जोड़ना चाहता हूं, अगर आप खुद को ऐसी परिस्थिति में पाते हैं जब आपको पहले से चलने वाली प्रक्रिया को रखना होगा screen, प्रयत्न reptyr। - a sad dude


जवाब:


2016 के लिए संपादित करें:

यह क्यू एंड ए भविष्यवाणी करता है systemd v230 हार। Systemd v230 के रूप में, नया डिफ़ॉल्ट एक अंतिम लॉगिन सत्र के सभी बच्चों को मारना है, इस पर ध्यान दिए बिना कि इसे रोकने के लिए ऐतिहासिक रूप से वैध सावधानी बरतनी चाहिए। सेटिंग को बदलकर बदला जा सकता है KillUserProcesses=no में /etc/systemd/logind.conf, या उपयोगकर्ता स्पेस में एक डिमन शुरू करने के लिए systemd- विशिष्ट तंत्र का उपयोग करके circumvented। वे तंत्र इस प्रश्न के दायरे से बाहर हैं।

नीचे दिया गया पाठ वर्णन करता है कि लिनक्स से अधिक समय तक यूनिक्स डिज़ाइन स्पेस में चीजें पारंपरिक रूप से कैसे काम करती हैं।


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

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

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

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

टर्मिनल मल्टीप्लेक्सर्स आपके खोल पर्यावरण को डिस्कनेक्शन के बीच बरकरार रखने का एक आम तरीका है। वे आपको अपनी खोल प्रक्रियाओं से इस तरह से अलग करने की अनुमति देते हैं कि आप बाद में उनसे दोबारा संपर्क कर सकें, भले ही वह डिस्कनेक्शन आकस्मिक या जानबूझकर हो। tmuxतथा screen अधिक लोकप्रिय हैं; उनका उपयोग करने के लिए वाक्यविन्यास आपके प्रश्न के दायरे से बाहर है, लेकिन वे देखने लायक हैं।


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

इस विशेष संदर्भ में, लिखने के लिए सबसे अधिक संभावना वाले कारक हैं:

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

टीसीपी सत्रों के लिए सामान्य नियम यहां लागू होते हैं: यदि ग्राहक और सर्वर के बीच कनेक्टिविटी में कोई रुकावट है, लेकिन न तो पक्ष समस्या के दौरान एक पैकेट भेजने का प्रयास करता है, तो कनेक्शन जीवित रहेगा बशर्ते दोनों पक्ष उत्तरदायी हों और अपेक्षित टीसीपी प्राप्त करें अनुक्रम संख्याएं

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


108
2018-01-06 04:36



मैं उस सूची में 'dtach' कमांड भी जोड़ूंगा - यह स्क्रीन / टीएमयूक्स के विपरीत है जिसमें यह आपको कई टर्मिनल को एक सत्र में संलग्न करने देता है, और सत्र को लंबे समय तक बढ़ाने के लिए भी बहुत अच्छा है, हालांकि यह नहीं है हालिया इतिहास को फिर से चलाने का कोई साधन प्रदान करें। - fluffy
dtach यूआरएल यहाँ है: dtach.sourceforge.net - slm
उत्कृष्ट स्पष्टीकरण। मैं पहले से ही अधिक linuxey महसूस करता हूँ! - fregas
साथ ही, यह तकनीकी रूप से आपके उत्तर का हिस्सा नहीं है, यहां एक सामान्य बात है: आप इसका उपयोग कर सकते हैं kill -HUP किसी के टर्मिनल को लटकने के लिए मजबूर करने के लिए रूट के रूप में। आपको अच्छे कारण के बिना ऐसा नहीं करना चाहिए। जब मैं रखरखाव के दौरान चलने वाले गोले छोड़ देता हूं तो मुझे इसके अधिकांश लाभ मिलते हैं और मुझे एक फाइल सिस्टम को अनमाउंट करने की आवश्यकता होती है कि उनका खोल खुला रहता है। यदि उपयोगकर्ता कनेक्ट है लेकिन टर्मिनल निष्क्रिय है, तो सिग्नल को अपनी एसएसडीडी प्रक्रिया में भेजें। अन्यथा, यदि यह टर्मिनल मल्टीप्लेक्सर के अंदर चल रहा है, तो उसे उस शेल पर भेजें जिसे आप रोकना चाहते हैं। काम करने से आपको केवल खोल को लटकाओ! - Andrew B
@AndrewB, क्या आप कृपया बता सकते हैं कि "एसएसएच डिमन प्रक्रिया कैसे ... निर्णय लेती है कि आपका कनेक्शन मर चुका है"? और मुझे कैसे पता चलेगा कि एसएसएच डिमन सोचता / जानता है कि (कौन सा) कनेक्शन मर चुका है या नहीं? - Xiao Peng - ZenUML.com


जैसा कि दूसरे ने उल्लेख किया है, एक बार जब आप एसएसएच से डिस्कनेक्ट कर लेते हैं तो कुछ भी चला जाता है।

जैसा @ माइकल हैम्पटन और अन्य ने उल्लेख किया है कि आप उपकरण का उपयोग कर सकते हैं tmux या screen अपनी सामग्री खोने के बिना टर्मिनल को डिस्कनेक्ट / रीकनेक्ट करने के लिए (यानी बाल प्रक्रियाएं)।

इसके अतिरिक्त आप एक एम्पर्सेंड का उपयोग कर पृष्ठभूमि में एक प्रक्रिया डाल सकते हैं & और उसके बाद कमांड का उपयोग करें disown वर्तमान खोल के साथ उन्हें अलग करने के लिए।

# start a command
% sleep 5000 &
[1] 3820

# check it
% jobs
[1]+  Running                 sleep 5000 &

# disown everything
% disown -a

# check it again (gone from shell)
% jobs
%

# but it's still running on the system
% ps -eaf|grep "[s]leep"
saml      3820 23791  0 00:16 pts/1    00:00:00 sleep 5000
%

21
2018-01-06 05:27



क्या टर्मिनल सत्र को दोबारा जोड़ना संभव है disownएड प्रक्रिया? - Fake Name
हाँ। विवरण के लिए यह यू एंड एल प्रश्न देखें: unix.stackexchange.com/questions/4034/... - slm


नहीं, टर्मिनल से अभी भी कोई प्रोग्राम जुड़ा हुआ है, और पृष्ठभूमि में कुछ ऐसा नहीं है nohup, मारा जाएगा।

यही कारण है कि वर्चुअल टर्मिनल समाधान जैसे हैं tmux और पुराना screen जो सत्र बनाते हैं जो चलते रहें, भले ही आप डिस्कनेक्ट हो जाएं, और जिसके बाद आप बाद में दोबारा जुड़ सकें।


11
2018-01-06 03:16