क्यों "su -c <कमांड> &" प्रतीत होता है कि एक कमांड बैकग्राउंड में बिना लटकाए चलने की अनुमति देता है


11

मैं एक सहकर्मी की मदद कर रहा था, जिसे पृष्ठभूमि की प्रक्रिया में रुक-रुक कर समस्या आ रही थी।

मुझे पता चला कि वे सर्वर पर लॉग इन करके और निष्पादित करके पृष्ठभूमि की प्रक्रिया शुरू कर रहे थे:

su - <user> -c '<command>' &

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

हमने अपनी बात प्रदर्शित करने के लिए उपरोक्त कमांड का परीक्षण किया और ... यह काम करने लगा: कमांड द्वारा शुरू की गई प्रक्रिया तब बाहर नहीं निकली जब हमने उपरोक्त कमांड को चलाने वाले टर्मिनल से बाहर निकल गए।

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

जैसा आदेश अपेक्षित हो वैसा ही चल रहा है:

<command> &
exit

उपरोक्त मामले में जब हम टर्मिनल से बाहर निकलते हैं तो कमांड द्वारा शुरू की गई पृष्ठभूमि प्रक्रिया समाप्त हो जाती है।

मेरा सवाल यह है:

  1. जब हम "su - -c &" जोड़ते हैं तो क्या होता है जो हमारे टर्मिनल से बाहर निकलने पर प्रक्रिया को बाहर निकलने से रोकता है। मैं नियंत्रण टर्मिनल, मानक इनपुट और आउटपुट आदि के संबंध में विस्तार से समझना चाहूंगा।

  2. क्या इस आदेश को पृष्ठभूमि प्रक्रिया के रूप में चलाने के लक्ष्य को प्राप्त करने का यह एक उचित तरीका है। यदि नहीं, तो क्यों नहीं?

मैं अपनी कंपनी के भीतर सर्वोत्तम प्रथाओं का प्रचार करना चाहता हूं, लेकिन मुझे जो भी सिफारिशें प्रदर्शित करने और बैक-अप करने में सक्षम होना चाहिए।

मैं यह भी समझना चाहता हूं कि वास्तव में क्या हो रहा है।

जवाबों:


12

मरने के टर्मिनल की वजह से एक प्रक्रिया को मारने के कई तरीके हो सकते हैं।

  1. पहला तरीका कर्नेल में टर्मिनल ड्राइवर वह यह है कि एक SIGHUP संकेत भेजता है को नियंत्रित करने की प्रक्रिया है जिसके लिए टर्मिनल है नियंत्रित टर्मिनल । ज्यादातर मामलों में, नियंत्रण प्रक्रिया वह शेल है जिसे शुरू में टर्मिनल में शुरू किया गया था, और इसका नियंत्रण टर्मिनल वह है जो इसके स्टड, स्टडआउट और स्टडर से जुड़ा हुआ है। कॉल करने पर नियंत्रण टर्मिनल से एक प्रक्रिया काट दी जाती है setsid

  2. दूसरा तरीका यह है कि शेल, जब वह SIGHUP प्राप्त करता है, तो उस सिग्नल को अपने उपप्रोसेस पर दोबारा भेजता है - अधिक सटीक रूप से, अपनी पृष्ठभूमि की नौकरियों के लिए। कुछ गोले (ksh, bash, zsh) के पास disownशेल को यह बताने के लिए एक शेल होता है कि किसी विशेष कार्य के लिए SITEUP नहीं भेजा जाना चाहिए।

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

तो suयहाँ क्या परिवर्तन है (2) सामान्य रूप से पृष्ठभूमि कार्य को मारने के लिए प्रारंभिक शेल का कारण होगा, लेकिन चूंकि पृष्ठभूमि प्रक्रिया एक अलग उपयोगकर्ता के रूप में चल रही है, इसलिए संकेत वितरित नहीं किया जा सकता है, और पृष्ठभूमि प्रक्रिया चालू रहती है।


मैंने रूट यूजर को करते देखा है chroot --userspec root:root / sh -c "exec some_forever_process" &। नौकरी उसी उपयोगकर्ता के रूप में चल रही है, जिसके nohupपहले या disownबाद में कोई स्पष्ट नहीं है । तो इस मामले के लिए, यह कैसे संकेत दिया जा सकता है कि टर्म एग्जिट पर वितरित नहीं किया जा सकता है।
टोड्डियस ज़ो

@ToddiusZho प्रकल्पनीय some_forever_processका इरादा हमेशा के लिए (एक डेमन) चलाने का था और इसलिए टर्मिनल से बाहर निकलने (अपने स्वयं के प्रक्रिया समूह में चलाकर) से स्वयं को सुरक्षित रखने से बचाता है।
गिलेस एसओ- बुराई को रोकना '

bash / tail SIGHUP के खिलाफ सुरक्षा नहीं करता है, फिर भी वह काम करता है: `` स्थानीय $ ssh रूट @ REMOTE_HOST रिमोट # chroot --userspec रूट: root / sh -c "exec bash -c 'tail -f / dev / null '' & [1] 6376 रिमोट # ps -p $! -कोई-हेडिंग -o pid, uid, command -ww 6376 0 tail -f / dev / null रिमोट # एग्जिट लोकल $ ssh रूट @ REMOTE_HOST रिमोट # ps -p 6376 --no-heading -o -id, uid, कमांड -W6376 0 पूंछ -f / देव / अशक्त `` `
टोडिडियस झो
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.