बैश SIGTERM को अनदेखा क्यों करता है?

Question

कभी-कभी जब मैं जल्दी से लॉगआउट करना चाहता हूं तो करता हूं kill -15 -1। मैंने देखा है कि बैश SIGTERM की अनदेखी कर रहा है।

मुझे आश्चर्य है कि इस तरह के बकवास व्यवहार के लिए तर्क क्या है ?

यह एक बहुत अच्छा कारण के बिना SIGTERM को अनदेखा करने के लिए बहुत अच्छा नहीं है, है ना?

अपडेट करें:

सभी के लिए समान (नहीं) प्रभाव:

$ kill -TERM $$
$ type kill
kill is a shell builtin
$ command kill -TERM $$
$ /bin/kill -TERM $$

UPDATE2:

से आदमी पार्टी :

जब बैश इंटरैक्टिव होता है, तो किसी भी जाल के अभाव में, यह SIGTERM को नजरअंदाज करता है

तो यह उद्देश्य पर किया गया है। लेकिन क्यों?

Comments

तुम कौन सी मार खा रहे हो? /bin/killया शेल बिलिन? यदि उत्तरार्द्ध, मैं अनुमान लगा रहा हूं कि शेल अपने बिलिन के साथ खुद को नहीं मारेगा।

— terdon

@terdon: मैंने बिलिन का उपयोग किया है, लेकिन मुझे नहीं लगता कि यह आत्म हत्या न करने का कारण है।

— मिशैल errajer

अगर आप जल्दी लॉगआउट करना चाहते हैं तो

— YoMismo

@YoMismo: "एक्स सत्र से लॉगआउट"

— मिकेल

@ माइकेलरजेर: Ctrl-Alt-Backspace मेरे लिए यह Xorg पर करता है ... आपको इसे xorg.conf में सक्षम करना पड़ सकता है, हालांकि।

— लास्ज़्लो वल्को

Answer 1

सबसे पहले, यह बैश करने के लिए विशिष्ट नहीं है। ATT ksh, डैश और zsh समान व्यवहार करते हैं: वे कमांड लाइन संस्करण के दौरान SIGTERM और SIGQUIT को अनदेखा करते हैं; mksh के रूप में, यह भी नहीं छोड़ता है लेकिन उन्हें SIGINT की तरह व्यवहार करता है।

दोनों ksh मैनुअल और बैश मैनुअल इन शब्दों में SIGTERM की अनदेखी को सही ठहराते हैं:

ताकि kill 0एक इंटरेक्टिव शेल न मारें

kill 0प्रक्रिया समूह में सभी प्रक्रियाओं को मारता है कि शेल in the है। संक्षेप में, प्रक्रिया समूह में टर्मिनल पर अग्रभूमि में चलने वाली सभी प्रक्रियाएँ होती हैं, या सभी प्रक्रियाएँ पृष्ठभूमि या निलंबित कार्य में होती हैं।

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

हालांकि ऐसी ही अन्य स्थितियां भी हैं जहां शेल इम्यून को उपयोगी बनाता है। उस मामले पर विचार करें जहां आपके पास एक टर्मिनल को हॉगिंग करने की प्रक्रिया है और आप लॉग आउट किए बिना उन्हें मारना चाहते हैं। कई प्रणालियों में एक उपकरण होता है, pkillजो आपको टर्मिनल पर चलने वाली प्रक्रियाओं को मारने देता है। आप मौजूदा टर्मिनल पर चलने वाली सभी प्रक्रियाओं को चलाने pkill -t $TTYया pkill -QUIT -t $TTYमारने के लिए खोल को छोड़कर, जो सिग्नल की अनदेखी करते हैं।

एक शेल आम तौर पर या तो तब चला जाता है जब उपयोगकर्ता इसे बाहर निकालता है (जैसे exitया जैसे कमांड के साथ logout), या जब इसका टर्मिनल इनपुट के अंत का संकेत देता है (उपयोगकर्ता Ctrl+ दबाकर इसका कारण बन सकता है D) या पूरी तरह से चला जाता है। इस अंतिम स्थिति में, शेल सिग्नल SIGHUP प्राप्त करता है, और यह उस एक को अनदेखा नहीं करता है।

एक्स सत्र से लॉग आउट करने के आपके उपयोग के मामले के kill -15 -1लिए, यह करेगा, क्योंकि यह टर्मिनल एमुलेटर को मारता है जो शेल को राइट्स प्राप्त करने का कारण बनता है। यह वास्तव में एक्स सर्वर को मारने के लिए पर्याप्त है, लेकिन इसकी प्रक्रिया आईडी खोजने की आवश्यकता है। यदि आप पाठ सत्र पर काम करने के लिए समान कमांड चाहते हैं, तो आप उपयोग कर सकते हैं kill -15 -1; exit। यह वैसे भी अपनी उंगलियों पर होने के लिए काफी खतरनाक आदेश है।

¹ _{यह एक नियम के रूप में शेल मैनुअल में उल्लिखित नहीं लगता है; यह अंतर्निहित सिस्टम कॉल की एक विशेषता है। यह स्पष्ट रूप से POSIX विनिर्देशन में उल्लिखित है ।}
To _{आजकल, ऐसा करने के लिए, jobs -lउनके प्रक्रिया समूह आईडी के साथ नौकरियों की सूची देखने के लिए दौड़ें , फिर kill -123 -456 …प्रक्रिया समूहों को मारने के लिए।}

Answer 2

यह आपके प्रश्न का उत्तर दे सकता है:

जब बैश इंटरैक्टिव होता है, तो किसी भी जाल की अनुपस्थिति में, यह SIGTERM (ताकि 'मार 0' एक इंटरेक्टिव शेल को नहीं मारता है) को नजरअंदाज कर देता है, और SIGINT को पकड़ लिया जाता है और हैंडल किया जाता है (ताकि प्रतीक्षा बेसिन बाधित हो)। जब बैश को एक संकेत मिलता है, तो यह किसी भी निष्पादित छोरों से बाहर हो जाता है। सभी मामलों में, बैश SIGQUIT की उपेक्षा करता है। यदि जॉब कंट्रोल प्रभाव में है (जॉब कंट्रोल देखें), बैश SIGTTIN, SIGTTOU और SIGTSTP को अनदेखा करता है।

बैश द्वारा शुरू किए गए गैर-बिलिन आदेशों में सिग्नल हैंडलर को अपने माता-पिता से शेल द्वारा विरासत में प्राप्त मूल्यों के लिए सेट किया गया है। जब नौकरी पर नियंत्रण प्रभावी नहीं होता है, तो एसिंक्रोनस कमांड इन विरासत वाले हैंडलर के अलावा SIGINT और SIGQUIT को अनदेखा कर देते हैं। कमांड प्रतिस्थापन के परिणामस्वरूप चलने वाले कमांड कीबोर्ड-जनरेट किए गए जॉब कंट्रोल सिग्नल SIGTTIN, SIGTTOU और SIGTSTP को अनदेखा करते हैं।

किसी SITEUP के प्राप्त होने पर शेल डिफ़ॉल्ट रूप से बाहर निकलता है। बाहर निकलने से पहले, एक इंटरेक्टिव शेल सभी जॉब के लिए, रनिंग या रोके जाने के लिए SITEUP का समर्थन करता है। बंद नौकरियों को SIGCONT भेजा जाता है ताकि यह सुनिश्चित किया जा सके कि वे SIGHUP प्राप्त करते हैं। शेल को किसी विशेष कार्य के लिए SITEUP सिग्नल भेजने से रोकने के लिए, उसे जॉब टेबल से हटाए गए बिलिन (जॉब कंट्रोल बिल्डिंस देखें) के साथ हटा दिया जाना चाहिए या डिस -एच का उपयोग करके SIGHUP प्राप्त नहीं करने के लिए चिह्नित किया जाना चाहिए।

यदि हूपोनेक्सिट शेल विकल्प शॉपट के साथ सेट किया गया है (देखें द शाप्ट बिलिन), बैश इंटरैक्टिव जॉब शेल से बाहर निकलने पर सभी नौकरियों के लिए एक साइट भेजता है।

यदि बैश एक कमांड को पूरा करने के लिए इंतजार कर रहा है और एक संकेत प्राप्त करता है जिसके लिए एक जाल सेट किया गया है, तो कमांड पूरा होने तक जाल को निष्पादित नहीं किया जाएगा। जब बैश वेट बिलिन के माध्यम से एक अतुल्यकालिक कमांड की प्रतीक्षा कर रहा है, तो एक सिग्नल का रिसेप्शन जिसके लिए एक जाल स्थापित किया गया है, प्रतीक्षा बायिन को तुरंत बाहर निकलने की स्थिति में 128 से अधिक के साथ वापस लौटने का कारण होगा, जिसके तुरंत बाद ट्रैप निष्पादित हो जाता है।

स्रोत : GNU बैश मैनुअल

Comments

मैंने इसे अपने अपडेट 2 में उद्धृत किया। मनुष्य कहता है कि मार तो ऐसा कर रहा है, लेकिन यह नहीं समझाता कि ऐसा निर्णय क्यों लिया गया। सवाल बना हुआ है - क्यों?

— मीकल errajer