लॉग आउट करने के बाद भी मेरी प्रक्रिया क्यों चल रही है?


10

में लॉग इन करने के बाद ssh, मैं यह कमांड टाइप करता हूं bash:

sleep 50000000000000 &

तब मैं प्रक्रिया की मूल प्रक्रिया (यानी, )। फिर टर्मिनल विंडो एक साथ डिस्कनेक्ट होती है।kill -9sleepbash

जब मैं फिर से लॉग इन करता हूं, तो पाता हूं कि यह sleepप्रक्रिया अभी भी जीवित है।

प्रश्न : sleepजब मैं लॉग आउट करता हूं और टर्मिनल बंद होता है तो प्रक्रिया क्यों बच सकती है? मेरे दिमाग में, डेमॉन और nohupकार्यक्रमों को छोड़कर सब कुछ लॉगआउट के दौरान मारा जाएगा। अगर sleepइस तरह से बच सकते हैं, तो क्या इसका मतलब यह है कि मैं इस पद्धति का उपयोग nohupकमांड के बजाय कर सकता हूं ?


3
&पृष्ठभूमि (डेमन की तरह) के लिए प्रक्रिया को कांटा जाएगा और आप लॉग आउट होने के बाद भी लगातार चल रहे हैं।
ऐजुद्दीन ज़ली

जवाबों:


6

Tl, डॉ:

sleepजब मैं लॉग आउट करता हूं और टर्मिनल बंद रहता है तो प्रक्रिया क्यों बच सकती है? मेरे दिमाग में, डेमॉन और nohupकार्यक्रमों को छोड़कर सब कुछ लॉगआउट के दौरान मारा जाएगा। अगर sleepइस तरह से बच सकते हैं, तो क्या इसका मतलब यह है कि मैं इस पद्धति का उपयोग nohupकमांड के बजाय कर सकता हूं ?

जब तक bashउदाहरण के द्वारा पैदा की sshहै huponexitविकल्प सेट, कोई प्रक्रिया बाहर निकलने पर किसी भी मतलब द्वारा समाप्त किया जाएगा / लॉग आउट करें और जब huponexitविकल्प सेट किया गया है, का उपयोग कर kill -9खोल पर उपयोग करने के लिए एक अच्छा विकल्प नहीं है nohupखोल के बच्चे की प्रक्रिया पर; nohupशेल के बच्चे की प्रक्रिया अभी भी उन्हें शेल से नहीं आने वाले SUPUP से सुरक्षित रखेगी, और तब भी जब यह महत्वपूर्ण नहीं nohupहै तब भी इसे पसंद नहीं किया जाएगा क्योंकि यह शेल को शान से समाप्त करने की अनुमति देता है।


इसमें bashएक विकल्प होता है huponexit, जिसे यदि सेट bashआउट / लॉगआउट पर अपने बच्चों को SITEUP बना देगा ;

इंटरएक्टिव नॉन-लॉगिन bash उदाहरणों में, जैसे कि bashउदाहरण के द्वारा gnome-terminal, इस विकल्प को अनदेखा किया जाता है; चाहे huponexitवह सेट हो या bashपरेशान bash, बाहर निकलने से बच्चे कभी भी बीमार नहीं होंगे ;

इंटरेक्टिव लॉगिन bash इंस्टेंस में, जैसे कि bashउदाहरण के द्वारा ssh, इस विकल्प को अनदेखा नहीं किया जाता है (हालाँकि यह डिफ़ॉल्ट रूप से परेशान है); यदि huponexitसेट किया गया है, तो bashबच्चों को bashबाहर निकलने / लॉगआउट करने से साइटअप हो जाएगा ; यदि कोई परेशान है huponexit, तो bashबच्चों के bashबाहर निकलने / लॉगआउट करने से SIGHUPped नहीं होगा ;

इसलिए सामान्य रूप से एक इंटरेक्टिव लॉगिन bashउदाहरण से बाहर निकलने / लॉगिंग करने के लिए, जब तक कि huponexitविकल्प सेट नहीं किया जाता है, शेल को अपने बच्चों को SITEUP नहीं बनायेगा, और एक इंटरैक्टिव गैर-लॉगिन bashउदाहरण से बाहर निकलने / लॉगिंग करने से शेल अपने बच्चों को SITEUP नहीं बना सकेगा परवाह किए बिना;

हालाँकि, यह इस मामले में अप्रासंगिक है: उपयोग करने kill -9 sleepकी परवाह किए बिना बच जाएगा, क्योंकि इसकी मूल प्रक्रिया ( bash) को मारने से बाद वाले को पूर्व के लिए कुछ भी करने का मौका नहीं मिलेगा (जैसे, यदि वर्तमान bashउदाहरण एक लॉगिन bashउदाहरण था और huponexitविकल्प सेट किया गया था, इसे SIGHUP करने के लिए)।

अन्य संकेतों के विपरीत इसे जोड़ना (जैसे एक SIGHUP संकेत भेजा जाता है bash), एक SIGKILL सिग्नल को कभी भी किसी प्रक्रिया की बाल प्रक्रियाओं के लिए प्रचारित नहीं किया जाता है, इसलिए sleepइसे भी नहीं मारा जाता है;

nohupSIGHUP संकेतों के लिए एक प्रक्रिया प्रतिरक्षा शुरू करता है, जो कुछ अलग है; यह SIGHUP सिग्नल के रिसेप्शन पर लटकने वाली प्रक्रिया को रोक देगा, जो कि इस bashमामले में huponexitविकल्प के सेट होने और शेल से बाहर निकलने की स्थिति में इंटरेक्टिव लॉगिन इंस्टेंस द्वारा प्राप्त किया जा सकता है ; इसलिए तकनीकी रूप से विकल्प के साथ nohupएक इंटरेक्टिव लॉगिन bashइंस्टेंस में एक प्रक्रिया शुरू करने के लिए उपयोग करने से huponexitविकल्प प्रक्रिया को एक साइट सिग्नल के रिसेप्शन पर लटकने से रोक देगा, लेकिन शेल से बाहर निकलने / लॉगिंग करने के बावजूद इसे अलग नहीं करेगा;

सामान्य तौर पर, हालांकि, जब nohupमाता-पिता के खोल से आने वाले सिग्नल संकेतों को रोकने की आवश्यकता होती है , तो चाइल्ड पद्धति पर kill -9माता-पिता की विधि पर पसंद करने का कोई कारण नहीं है nohup; इसके बजाय, यह विपरीत होना चाहिए।

kill -9विधि का उपयोग करते हुए माता-पिता को मारना माता- पिता के लिए शालीनता से बाहर निकलने का मौका नहीं छोड़ता है, जबकि nohupविधि का उपयोग करके बच्चे को शुरू करना माता-पिता को अन्य संकेतों द्वारा समाप्त करने की अनुमति देता है, जैसे कि SIGHUP (एक उदाहरण बनाने के लिए जो संदर्भ में समझ में आता है एक बच्चे ने उपयोग करना शुरू कर दिया nohup), जो इसे इनायत से बाहर निकलने की अनुमति देता है।


दूसरे शब्दों में, अगर मेरे पास एक स्क्रिप्ट है जो पृष्ठभूमि में रखी गई थी, तो यह अभी भी चल रही होगी, भले ही मैं मूल प्रक्रिया को मार दूं, जैसे कि मेरा शेल सही है? उस स्क्रिप्ट को मारने का एक तरीका क्या होगा?
सर्गी कोलोडियाज़नी

@ यदि आपके पास पीआईडी ​​है, तो बस पीआईडी ​​को मारना; यदि आपने PID को संग्रहीत नहीं किया है, लेकिन आप उसके नाम से प्रक्रिया की पहचान कर सकते हैं, ps -e | grep processतो PID के साथ ही प्रॉसेस को सूचीबद्ध करना चाहिए (या बेहतर pgrep -x processयदि आप उस एकल प्रक्रिया से मेल खाने के लिए सुनिश्चित हैं और अवांछित चीजें नहीं हैं); समस्या यह है कि जब आप kill -9अपने बच्चों के साथ एक प्रक्रिया को मार देते हैं upstart, तो उनका मूल पीपीआईडी ​​खो जाता है और उनके पीपीआईडी ​​को बदलकर पीआईडी ​​को बदल दिया जाता है, जिससे वे अपरिचित (एएफएआईके) बन जाते हैं, लेकिन उनके नाम या पीआईडी ​​के लिए
कोस

@kos किस प्रक्रिया के तहत nohupमूल प्रक्रिया से SITEUP सिग्नल प्राप्त करने पर किसी प्रक्रिया को लटकने से रोकने में विफल होगी? मैं पृष्ठभूमि में (एक पुष्ट एसएसएच शेल टर्मिनल में) एक प्रक्रिया चलाने की कोशिश कर रहा हूं nohup <command> <arg> &। जब मैं PuTTY Xबटन पर क्लिक करके लॉगआउट करता हूं , तो पृष्ठभूमि प्रक्रिया तुरंत समाप्त हो जाएगी। जब मैं exitPuTTY SSH शेल टर्मिनल में टाइप करके लॉगआउट करता हूं , तो प्रक्रिया बैकग्राउंड में चलती रहेगी।
userpal

3

bashडिफ़ॉल्ट रूप से बाहर निकलने पर बच्चे की प्रक्रियाओं के लिए HUP सिग्नल को नीचे नहीं भेजता है । विस्तार से अधिक (धन्यवाद @kos), यह गैर-लॉगिन गोले के लिए कभी नहीं करता है ।

यदि आप विकल्प सेट करते हैं तो आप इसे लॉगइन गोले के लिए कर सकते हैं huponexit। एक टर्मिनल में, करें:

[romano:~] % bash -l

(यह एक नया "लॉगिन" शेल शुरू करें)

romano@pern:~$ shopt -s huponexit
romano@pern:~$ sleep 1234 &
[1] 32202
romano@pern:~$ exit
logout

अब sleepप्रक्रिया के लिए जाँच करें :

[romano:~] % ps augx | grep sleep
romano   32231  0.0  0.0  16000  2408 pts/11   S+   15:23   0:00 grep sleep

... नहीं चल रहा है: यह HUP संकेत प्राप्त हुआ है और अनुरोध के अनुसार बाहर निकल गया है।


@kos --- हाँ, आप सही हैं लेकिन ... तो अगर मैं बच sleep 1000 & ; exitगया तो क्यों sleep? सूचना है कि अगर मैं प्रक्रिया यह होगा बाहर निकलें। और सेट होने पर भी बच जाता है। भ्रमित ... (मैं बेहतर समझने और asnwer को संशोधित करने की कोशिश करूंगा, अन्यथा मैं इसे हटा दूँगा)। kill -HUPsleephuponexitsleep
रमनो

2

अगर sleepइस तरह से बच सकते हैं, अगर इसका मतलब है कि मैं इस विधि का उपयोग nohupकमांड के बजाय कर सकता हूं ?

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


जब मैं लॉगआउट और टर्मिनल बंद होता है तो नींद की प्रक्रिया क्यों बच सकती है। मेरे दिमाग में, लॉगऑन के दौरान डेमन और नोह के कार्यक्रम को छोड़कर सब कुछ मारा जाएगा।

आपके मामले में क्या होता है:

sleepवर्तमान में चल रही bashशैल की मूल प्रक्रिया है । जब आप kill -9उस बैश करते हैं, तो बैश प्रक्रिया को SIGHUPअपनी किसी भी बच्चे की प्रक्रिया को भेजने का मौका नहीं मिलता है, क्योंकि SIGKILL(जो द्वारा भेजा जाता है kill -9) प्रक्रिया द्वारा उपलब्ध नहीं है। नींद की प्रक्रिया जारी है। नींद अब एक अनाथ प्रक्रिया बन गई ।

Init (PID 1) प्रक्रिया एक तंत्र बनाती है जिसे पुनर्मिलन कहा जाता है। इसका मतलब यह है कि init प्रक्रिया अब उस अनाथ प्रक्रिया का जनक बन जाती है। init एक अपवाद है, प्रक्रियाएं बच्चे बन सकते हैं क्योंकि यह उन प्रक्रियाओं को एकत्र करता है जो अपनी मूल मूल प्रक्रिया खो देते हैं। Btw: एक डेमन (जैसे sshd) वह करता है जब "पृष्ठभूमि में जा रहा है"।

अगर ऐसा नहीं होता है, तो अनाथ प्रक्रिया बाद में (जब समाप्त हो जाएगी) एक ज़ोंबी प्रक्रिया बन जाएगी। ऐसा तब होता है जब waitpid()उसे नहीं बुलाया जाता है (मूल प्रक्रिया की एक जिम्मेदारी जो उस प्रक्रिया के मारे जाने पर पूरी नहीं हो सकती है)। init कॉल waitpid()ज़ोंबी चिल्ड से बचने के लिए एक विशिष्ट इंटरवेल में।


यह प्रक्रिया विनम्र संकेतों के साथ भी जीवित रही है जैसेTERMHUP
हेमायल

@ हेमेयल एचयूपी गोले विन्यास पर निर्भर करता है huponext:। और TERM का इंतजार तब तक होगा जब तक नींद पूरी नहीं हो जाती। ओप्स स्लीप कमांड के मामले में, यह हजारों साल =) होगा
अराजकता

1

&पृष्ठभूमि में प्रक्रिया शुरू होता है। यदि आप टाइप करते हैं ps -ef, तो आप देखेंगे कि आपकी नींद की मूल प्रक्रिया आईडी (PPID) आपकी बैश है। फिर लॉगआउट करें और फिर से लॉगिन करें। लॉगआउट करने के बाद प्रक्रिया चालू रहेगी। आपके द्वारा दूसरी बार लॉगिन करने के बाद आप ps -efफिर से चलते हैं । आप देखेंगे कि अब आपके स्लीप प्रोसेस का जनक id "1" के साथ प्रोसेस होगा। यह init, सभी प्रक्रियाओं का जनक है।


0

उपयोग करने &से प्रोग्राम को पृष्ठभूमि के रूप में चलाने का कारण होगा। बैकग्राउंड उपयोग bgकमांड में प्रोग्राम को देखने के लिए , और इसे फिर से अग्रभूमि के रूप में चलाने के लिए, चलाएं fg

हां, प्रोग्राम को चालू रखने के कई तरीके हैं यहां तक ​​कि मुख्य टर्मिनल से बाहर भी।


धन्यवाद। मार के आदमी पृष्ठ थोड़ा भ्रमित है। इसमें कहा गया है कि: "बाहर निकलने से पहले, एक इंटरैक्टिव शेल सभी नौकरियों के लिए SIGHUP का समाधान करता है, चल रहा है या बंद कर दिया गया है।" लेकिन वास्तव में, शेल केवल SUBUP को फ़ोरग्राउंड नौकरियों में भेजता है । बैकग्राउंड प्रोसेस में SIGHUP सिग्नल प्राप्त करने का कोई मौका नहीं है (जब तक कि 'huponexit' शेल ऑप्शंस न बदलें)
tom_cat

@kos शायद आप सही हैं। मैं इस पोस्ट से उपरोक्त निष्कर्ष निकालता हूं : stackoverflow.com/questions/4298741/… अब, मैं खुद को और अधिक भ्रमित करता हूं।
tom_cat

@tom_cat इस पर फिर से विचार करें, इसके बारे में दो बार सोचें: ऐसा कोई मामला नहीं है जिसमें शेल एक अग्रभूमि प्रक्रिया से बाहर निकल सकता है , यह SIGHUPped या कुछ और हो सकता है, लेकिन यह बाहर नहीं निकल रहा है । तो यह सही है, यह केवल पृष्ठभूमि प्रक्रियाओं पर लागू होता है, क्योंकि इसके विपरीत कोई मतलब नहीं होगा। हालाँकि, आगे के शोध से यह भी पता चलता है कि huponexitलॉगिन गोले पर काम करता है जैसे कि एक शेल के माध्यम से प्राप्त किया जाता है ssh(और नहीं, कहते हैं, के माध्यम से प्राप्त शेल में gnome-terminal)
कोस
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.