पर आदमी पेज , यह सिर्फ कहते हैं:
-m नौकरी नियंत्रण सक्षम है।
लेकिन वास्तव में इसका क्या मतलब है?
मैं एक एसओ प्रश्न में इस कमांड पर आया था , मुझे ओपी के रूप में एक ही समस्या है, जो "फैब्रिक टॉककॉट शुरू नहीं कर सकता है"। और इसका set -mहल निकाला। ओपी ने थोड़ा समझाया, लेकिन मुझे समझ नहीं आया:
यह मुद्दा पृष्ठभूमि के कार्यों में था क्योंकि कमांड समाप्त होने पर वे मारे जाएंगे।
समाधान सरल है: बस "सेट -m;" जोड़ें कमांड से पहले उपसर्ग।
जवाबों:
बैश प्रलेखन उद्धृत (से man bash):
JOB CONTROL
Job control refers to the ability to selectively stop
(suspend) the execution of processes and continue (resume)
their execution at a later point. A user typically employs
this facility via an interactive interface supplied jointly
by the operating system kernel's terminal driver and bash.
इसलिए, काफी सरल रूप से कहा गया है, set -m(इंटरैक्टिव गोले के लिए डिफ़ॉल्ट) किसी को अंतर्निहित इन्स जैसे कि fgऔर bg, जो कि set +m(गैर-संवादात्मक गोले के लिए डिफ़ॉल्ट) के तहत अक्षम किया जाएगा ।
यह मेरे लिए स्पष्ट नहीं है कि नौकरी नियंत्रण और बाहर निकलने पर पृष्ठभूमि प्रक्रियाओं को मारने के बीच क्या संबंध है, हालांकि, लेकिन मैं यह पुष्टि कर सकता हूं कि एक है: चल रही set -m; (sleep 10 ; touch control-on) &फ़ाइल को बनाएगी यदि कोई उस कमांड को टाइप करने के बाद शेल को सही छोड़ता है, लेकिन set +m; (sleep 10 ; touch control-off) &नहीं।
मुझे लगता है कि इसका उत्तर बाकी दस्तावेजों में निहित है set -m:
-m Monitor mode. [...] Background pro‐
cesses run in a separate process group and a line con‐
taining their exit status is printed upon their comple‐
tion.
इसका मतलब यह है कि पृष्ठभूमि के तहत शुरू की गई नौकरियां set +mवास्तविक "पृष्ठभूमि प्रक्रियाएं" नहीं हैं ("पृष्ठभूमि प्रक्रियाएं वे हैं जिनकी प्रक्रिया समूह आईडी टर्मिनल के" से भिन्न होती है): वे उसी प्रक्रिया समूह आईडी को साझा करते हैं जो कि शेल ने शुरू किया था, बल्कि उनके पास होने के बजाय उचित पृष्ठभूमि प्रक्रियाओं की तरह प्रक्रिया समूह। यह उस व्यवहार की व्याख्या करता है जब शेल अपनी पृष्ठभूमि की कुछ नौकरियों से पहले चलता है: यदि मैं सही ढंग से समझता हूं, तो छोड़ने के दौरान, शेल के रूप में उसी प्रक्रिया समूह में प्रक्रियाओं के लिए एक संकेत भेजा जाता है (इस तरह पृष्ठभूमि की नौकरियों को मारना शुरू हुआ set +m), लेकिन नहीं अन्य प्रक्रिया समूहों में से एक (इस प्रकार अकेले सच पृष्ठभूमि प्रक्रियाओं को छोड़ना शुरू हुआ set -m)।
तो, आपके मामले में, startup.shस्क्रिप्ट संभवतः पृष्ठभूमि की नौकरी शुरू करती है। जब यह स्क्रिप्ट गैर-अंतःक्रियात्मक रूप से चलाई जाती है, जैसे कि SSH से अधिक के रूप में जिस प्रश्न से आप जुड़े हैं, नौकरी पर नियंत्रण अक्षम है, "पृष्ठभूमि" नौकरी दूरस्थ शेल के प्रक्रिया समूह को साझा करती है, और इस तरह उस शेल के बाहर निकलते ही मारा जाता है। इसके विपरीत, उस शेल में जॉब कंट्रोल को सक्षम करके, बैकग्राउंड जॉब अपने स्वयं के प्रोसेस ग्रुप का अधिग्रहण करता है, और जब इसका मूल शेल बाहर निकलता है तो उसे नहीं मारा जाता है।
मैं इसे github मुद्दे की सूची में मिला, और मुझे लगता है कि यह वास्तव में आपके प्रश्न का उत्तर देता है।
यह वास्तव में एक SSH समस्या नहीं है, यह BASH गैर-संवादात्मक / इंटरैक्टिव मोड और समूहों को संसाधित करने के लिए सिग्नल प्रसार के आसपास अधिक सूक्ष्म व्यवहार है।
इसके बाद /programming/14679178/why-does-ssh-wait-for-my-subshells-without-t-and-kill-them-with-t/14866774#14866774 और http: पर आधारित है। //www.itp.uzh.ch/~dpotter/howto/daemonize , कुछ मान्यताओं के साथ पूरी तरह से मान्य नहीं है, लेकिन यह कैसे काम करता है इसकी पुष्टि के लिए परीक्षण।
pty / tty = false
लॉन्च किया गया बैश शेल शुरू की गई प्रक्रिया के stdout / stderr / stdin से जोड़ता है और तब तक इसे चालू रखा जाता है जब तक कि सॉकेट्स के साथ कुछ भी जुड़ा नहीं होता है और यह बच्चों को बाहर निकाल देता है। एक अच्छी बहरी प्रक्रिया यह सुनिश्चित करेगी कि यह बच्चों के बाहर निकलने, बच्चे की प्रक्रिया को कांटे और फिर बाहर निकलने का इंतजार न करे। जब इस मोड में SSH द्वारा चाइल्ड प्रोसेस में कोई SIGHUP नहीं भेजा जाएगा। मेरा मानना है कि यह प्रक्रिया को निष्पादित करने वाली अधिकांश लिपियों के लिए सही ढंग से काम करेगा जो स्वयं को बहरा करने से निपटता है और इसे पृष्ठभूमि में रखने की आवश्यकता नहीं है। जहां init स्क्रिप्ट एक प्रक्रिया को पृष्ठभूमि करने के लिए '&' का उपयोग करते हैं, तो यह संभावना है कि मुख्य समस्या यह होगी कि क्या पृष्ठभूमि की प्रक्रिया कभी भी स्टड से पढ़ने का प्रयास करती है क्योंकि सत्र समाप्त हो गया है, तो वह एक SUPUP को ट्रिगर करेगा।
pty / tty = true *
यदि init स्क्रिप्ट बैकग्राउंड प्रोसेस शुरू हो जाता है, तो पैरेंट BASH शेल SSH कनेक्शन के लिए एक एक्जिट कोड लौटाएगा, जो तुरंत बाहर निकलने के लिए लुक देगा क्योंकि यह समाप्त होने के लिए बच्चे की प्रक्रिया का इंतजार नहीं कर रहा है और stdout पर ब्लॉक नहीं हुआ है। / stderr / stdin। इसके कारण SIGHUP को पैरेंट बैश शेल प्रोसेस ग्रुप में भेजा जाएगा, क्योंकि चूंकि जॉब कंट्रोल को बैश में नॉन-इंटरैक्टिव मोड में अक्षम किया गया है, इसलिए इसमें लॉन्च की गई चाइल्ड प्रॉसेस शामिल होंगी। जहां एक डेमॉन प्रक्रिया स्पष्ट रूप से एक नया प्रक्रिया सत्र शुरू करती है जब फोर्किंग या कांटे की प्रक्रिया में तब यह या यह बच्चे BASH मूल प्रक्रिया से बाहर निकलने से SIGHUP प्राप्त नहीं करेंगे। ध्यान दें कि यह निलंबित नौकरियों से अलग है जो एक SIGTERM को देखेगा। मुझे संदेह है कि इसके आसपास काम करने में कभी-कभी थोड़ी दौड़ की स्थिति के साथ काम करना पड़ता है। http://www.itp.uzh.ch/~dpotter/howto/daemonize , आप देखेंगे कि कोड में नया सत्र कांटे की प्रक्रिया द्वारा बनाया गया है जो कि माता-पिता के बाहर निकलने से पहले नहीं चलाया जा सकता है, इस प्रकार यादृच्छिक परिणाम होता है ऊपर उल्लिखित सक्सेस / असफलता व्यवहार। स्लीप स्टेटमेंट में कांटे की प्रक्रिया को नया सत्र बनाने के लिए पर्याप्त समय मिलेगा, यही कारण है कि यह कुछ मामलों के लिए काम करता है।
pty / tty = सच और नौकरी नियंत्रण को स्पष्ट रूप से bash में सक्षम किया गया है
SSH बैश शेल या किसी भी लॉन्च किए गए चाइल्ड प्रोसेस के stdout / stderr / stdin से कनेक्ट नहीं होगा, जिसका अर्थ यह होगा कि जैसे ही पेरेंट बैश शेल ने अनुरोध किए गए कमांड को निष्पादित करना शुरू किया। इस मामले में, जॉब कंट्रोल स्पष्ट रूप से सक्षम होने के साथ, बैश शेल द्वारा '' को बैकग्राउंड में लॉन्च करने वाली किसी भी प्रक्रिया को तुरंत एक अलग सत्र में रखा जाएगा और जब BASH सत्र के लिए मूल प्रक्रिया समाप्त हो जाती है, तो SIGHUP सिग्नल प्राप्त नहीं होगा ( इस मामले में एसएसएच कनेक्शन)।
क्या ठीक करने की जरूरत है
मुझे लगता है कि पृष्ठभूमि प्रक्रियाओं / सेवाओं के साथ काम करते समय समाधानों को विशेष रूप से रन / सुडो ऑपरेशंस डॉक्यूमेंटेशन में स्पष्ट रूप से उल्लिखित किया जाना चाहिए। मूल रूप से या तो 'pty = false' का उपयोग करते हैं, या जहां यह संभव नहीं है, स्पष्ट रूप से पहली कमांड के रूप में नौकरी नियंत्रण को सक्षम करता है, और व्यवहार सही होगा।
tomcat/bin/startup.shसे कैसे संबंधित है ?fgbg