जवाबों:
kill -9( SIGKILL ) हमेशा काम करता है, बशर्ते आपके पास प्रक्रिया को मारने की अनुमति हो। मूल रूप से या तो प्रक्रिया आपके द्वारा शुरू की जानी चाहिए और सेट्युइड या सेटगिड नहीं होनी चाहिए, या आपको रूट होना चाहिए। एक अपवाद है: यहां तक कि रूट पीआईडी 1 ( initप्रक्रिया) के लिए एक घातक संकेत नहीं भेज सकता है ।
हालांकि तुरंतkill -9 काम करने की गारंटी नहीं है । SIGKILL सहित सभी संकेतों को अतुल्यकालिक रूप से वितरित किया जाता है: कर्नेल को उन्हें वितरित करने में अपना समय लग सकता है। आमतौर पर, सिग्नल देने में ज्यादातर कुछ माइक्रोसेकंड लगते हैं, बस समय लगने पर टारगेट को पूरा करने में समय लगता है। हालाँकि, यदि लक्ष्य ने सिग्नल को ब्लॉक कर दिया है , तो सिग्नल को तब तक कतारबद्ध किया जाएगा जब तक कि लक्ष्य इसे अनब्लॉक नहीं करता।
आम तौर पर, प्रक्रिया SIGKILL को ब्लॉक नहीं कर सकती है। लेकिन कर्नेल कोड कर सकते हैं और प्रक्रियाएँ कर्नेल कोड निष्पादित करती हैं जब वे सिस्टम कॉल करते हैं । कर्नेल कोड सिस्टम सिग्नल को बाधित करते समय सभी संकेतों को अवरुद्ध करता है, जिसके परिणामस्वरूप कर्नेल में कहीं बुरी तरह से बनाई गई डेटा संरचना होती है, या आमतौर पर कुछ कर्नेल अपरिवर्तित उल्लंघन किया जाता है। इसलिए अगर (बग या गलत पहचान के कारण) सिस्टम अनिश्चित काल के लिए ब्लॉक कॉल करता है, तो प्रभावी रूप से प्रक्रिया को मारने का कोई तरीका नहीं हो सकता है। (लेकिन यह प्रक्रिया तब पूरी हो जाएगी जब यह सिस्टम कॉल पूरा कर लेगा ।)
सिस्टम कॉल में अवरुद्ध एक प्रक्रिया अबाधित नींद में है । psया topजाएगा आदेश (सबसे unices पर) राज्य में यह दिखाने D(मूलतः "के लिए घ ISK", मुझे लगता है)।
लंबे समय तक निर्बाध नींद का एक शास्त्रीय मामला एनएफएस पर फ़ाइलों तक पहुंचने की प्रक्रिया है जब सर्वर प्रतिक्रिया नहीं दे रहा है; आधुनिक कार्यान्वयन निर्बाध नींद (जैसे लिनक्स के तहत, intrमाउंट विकल्प एनएफएस फ़ाइल एक्सेस को बाधित करने के लिए एक संकेत की अनुमति देता है) को लागू नहीं करते हैं ।
आप कभी-कभी प्रविष्टियों को देख सकते हैं Z(या Hलिनक्स के तहत, मुझे नहीं पता कि क्या अंतर है) psया topआउटपुट में। ये तकनीकी रूप से प्रक्रिया नहीं हैं, वे ज़ोंबी प्रक्रियाएं हैं, जो प्रक्रिया तालिका में एक प्रविष्टि से ज्यादा कुछ नहीं हैं, चारों ओर रखी जाती हैं ताकि मूल प्रक्रिया को उसके बच्चे की मृत्यु के बारे में सूचित किया जा सके। जब मूल प्रक्रिया ध्यान देती है (या मर जाती है) तो वे चले जाएंगे ।
man 5 nfs: " कर्नेल 2.6.25 के बाद intr/ nointrमाउंट विकल्प को हटा दिया गया है। केवल SIGKILL इन कर्नेल पर लंबित NFS ऑपरेशन को बाधित कर सकता है, और यदि निर्दिष्ट किया जाता है, तो इस माउंट विकल्प को पुराने कर्नेल के साथ पश्चगामी संगतता प्रदान करने के लिए अनदेखा किया जाता है।"
sshfsप्रक्रिया को मार सकते हैं (और इसी तरह किसी अन्य FUSE फाइल सिस्टम के साथ: आप हमेशा इस तरह से बल-अनमाउंट कर सकते हैं)।
कभी-कभी प्रक्रिया मौजूद होती है और इसके कारण मारा नहीं जा सकता है:
topZ का संकेत दिया गया हैtopडी द्वारा संकेत दिया गया है।ऐसा लगता है कि आपके पास एक ज़ोंबी प्रक्रिया हो सकती है । यह हानिरहित है: केवल संसाधन जो ज़ोम्नि प्रक्रिया का उपभोग करता है वह प्रक्रिया तालिका में एक प्रविष्टि है। जब माता-पिता प्रक्रिया मर जाती है या अपने बच्चे की मृत्यु के प्रति प्रतिक्रिया करती है तो यह दूर हो जाएगा।
आप देख सकते हैं कि इस प्रक्रिया का उपयोग करके topया निम्नलिखित कमांड से एक ज़ोंबी है :
ps aux | awk '$8=="Z" {print $2}'
ps। यह सुनिश्चित किया जा सकता है कि सभी यूनियनों में सभी कार्यान्वयनों के साथ आवश्यक क्षेत्र हमेशा 8 वें स्थान पर psरहेगा?
किसी भी सुराग के लिए अपने /var/log/kern.logऔर /var/log/dmesg(या समकक्ष) की जाँच करें । मेरे अनुभव में यह मेरे साथ ही हुआ है जब एक एनएफएस माउंट का नेटवर्क कनेक्शन अचानक गिरा या डिवाइस ड्राइवर दुर्घटनाग्रस्त हो गया। अगर हार्ड ड्राइव दुर्घटनाग्रस्त हो जाए, तो मुझे विश्वास हो सकता है।
आप यह lsofदेखने के लिए उपयोग कर सकते हैं कि प्रक्रिया के पास कौन सी डिवाइस है जो खुली हुई है।
kill -9आमतौर पर 60 मिनट के इंतजार के बाद भी काम नहीं किया। एकमात्र समाधान रिबूट करना था।
यदि @ Maciej का और @ Gilles का उत्तर आपकी समस्या का समाधान नहीं करता है, और आप इस प्रक्रिया को नहीं पहचानते हैं (और यह पूछते हैं कि यह आपके डिस्ट्रो के साथ क्या है, तो उत्तर नहीं देता)। रूटकिट और किसी भी अन्य संकेत के लिए जांचें जो आपके स्वामित्व में हैं । एक रूटकिट आपको प्रक्रिया को मारने से रोकने में सक्षम से अधिक है। वास्तव में कई आपको देखने से रोकने में सक्षम हैं। लेकिन अगर वे 1 छोटे कार्यक्रम को संशोधित करना भूल जाते हैं तो उन्हें देखा जा सकता है (जैसे कि वे संशोधित top, लेकिन नहीं htop)। सबसे अधिक संभावना है कि यह मामला नहीं है लेकिन खेद से बेहतर सुरक्षित है।
किल का मतलब वास्तव में सिग्नल भेजना है। ऐसे कई संकेत हैं जिन्हें आप भेज सकते हैं। किल -9 एक विशेष संकेत है।
सिग्नल भेजते समय एप्लिकेशन इससे निपटता है। यदि कर्नेल इसके साथ व्यवहार नहीं करता है। तो आप अपने आवेदन में एक संकेत जाल कर सकते हैं।
लेकिन मैंने कहा कि किल -9 खास था। यह विशेष है कि अनुप्रयोग इसे प्राप्त नहीं करता है। यह सीधे कर्नेल पर जाता है जो तब अनुप्रयोग को पहले संभावित अवसर पर वास्तव में मारता है। दूसरे शब्दों में इसे मार डाला
किल -15 सिग्नल भेजता है SIGTERM जो दूसरे शब्दों में SIGNAL TERMINATE के लिए खड़ा है, आवेदन छोड़ने के लिए कहता है। किसी एप्लिकेशन को बंद करने का समय बताने का यह अनुकूल तरीका है। लेकिन अगर आवेदन जवाब नहीं मार रहा है -9 यह मार डालेगा।
अगर किल -9 काम नहीं करता है तो इसका मतलब है कि आपका कर्नेल अजीब से बाहर है। एक रिबूट क्रम में है। मुझे याद नहीं है कि कभी भी हो रहा है।
पहले, जांचें कि क्या इसकी ज़ोंबी प्रक्रिया (जो बहुत संभव है):
ps -Al
आप कुछ इस तरह देखेंगे:
0 Z 1000 24589 1 0 80 0 - 0 exit ? 00:00:00 soffice.bin <defunct>
(बाईं ओर "Z" नोट करें)
यदि 5 वां कॉलम 1 नहीं है, तो इसका मतलब है कि इसकी मूल प्रक्रिया है। उस मूल प्रक्रिया आईडी को मारने का प्रयास करें ।
अगर इसका PPID = 1 है, तो यह नहीं होगा !! , सोचें कि कौन से अन्य उपकरण या प्रक्रियाएं इससे संबंधित हो सकती हैं।
उदाहरण के लिए, यदि आप एक माउंटेड डिवाइस या सांबा का उपयोग कर रहे थे, तो इसे अनमाउंट करने का प्रयास करें। वह ज़ोंबी प्रक्रिया जारी कर सकता है।
नोट : यदि ps -Al(या top) "Z" के बजाय "D" दिखाता है, तो यह दूरस्थ माउंट (NFS की तरह) से संबंधित हो सकता है। मेरे अनुभव में, रिबूटिंग वहाँ जाने का एकमात्र तरीका है, लेकिन आप अन्य उत्तरों की जांच कर सकते हैं जो उस मामले को अधिक विस्तार से कवर करते हैं।
जैसा कि दूसरों ने उल्लेख किया है, अबाधित नींद में एक प्रक्रिया को तुरंत नहीं मारा जा सकता है (या, कुछ मामलों में, बिल्कुल)। यह ध्यान देने योग्य है कि एक अन्य प्रक्रिया राज्य, TASK_KILLABLE, को कुछ परिदृश्यों में इस समस्या को हल करने के लिए जोड़ा गया था, विशेष रूप से सामान्य मामला जहां प्रक्रिया NFS पर प्रतीक्षा कर रही है। Http://lwn.net/Articles/288056/ देखें
दुर्भाग्य से मुझे विश्वास नहीं है कि यह कर्नेल में कहीं भी उपयोग किया जाता है, लेकिन एनएफएस।
lsएक sshfsमाउंट तक पहुँचने वाली प्रक्रिया को मारने में समस्याएँ हुईं , जब रिमोट सर्वर के बेजोड़ होने की संभावना है। क्या FUSE या sshfs के लिए कोई समाधान है, जिसका उपयोग मैं भविष्य में ऐसी स्थितियों से बचने के लिए कर सकता हूं?
एक छोटी सी स्क्रिप्ट बनाई जिसने मुझे एक बार देखने में मदद की!
आप किसी भी प्रक्रिया को इसके मार्ग में दिए गए नाम के साथ मारने के लिए इसका उपयोग कर सकते हैं (इस पर ध्यान दें !!) या आप "-u उपयोगकर्ता नाम" पैरामीटर का उपयोग करके दिए गए उपयोगकर्ता की किसी भी प्रक्रिया को मार सकते हैं।
#!/bin/bash
if [ "$1" == "-u" ] ; then\n
PID=`grep "$2" /etc/passwd | cut -d ":" -f3`
processes=`ps aux | grep "$PID" | egrep -v "PID|ps \-au|killbyname|grep" | awk '{ print $2}'`
echo "############# Killing all processes of user: $2 ############################"
else
echo "############# Killing processes by name: $1 ############################"
processes=`ps aux | grep "$1" | egrep -v "killbyname|grep" | awk '{ print $2}' `
fi
for process in $processes ; do
# "command" stores the entire commandline of the process that will be killed
#it may be useful to show it but in some cases it is counter-productive
#command=`ps aux | grep $process | egrep -v "grep" | awk '{ print $2 }'`
echo "Killing process: $process"
echo ""
kill -9 $process
done
ऐसे मामले हैं जहां आप एक प्रक्रिया को किल -9 भेजते हैं, तो वह बंद हो जाएगा, लेकिन प्रक्रिया स्वचालित रूप से पुनरारंभ हो जाती है (उदाहरण के लिए, यदि आप इसके साथ प्रयास करते हैं gnome-panel, तो यह पुनरारंभ होगा): क्या यह मामला यहां हो सकता है?
जाँच करें कि क्या स्ट्रेस कुछ भी दिखाता है
strace -p <PID>
प्रक्रिया को gdb के साथ संलग्न करने का प्रयास करें
gdb <path to binary> <PID>
यदि यह प्रक्रिया एक ऐसे उपकरण के साथ बातचीत कर रही थी जिसे आप अनमाउंट कर सकते हैं, कर्नेल मॉड्यूल को हटा सकते हैं, या शारीरिक रूप से डिस्कनेक्ट / अनप्लग कर सकते हैं ... तो कोशिश करें।
मेरे पास इस तरह का मुद्दा था। यह एक ऐसा कार्यक्रम था जिसे मैंने + के straceसाथ लॉन्च किया था और इससे बाधित हुआ था । यह एक (पता लगाया या बंद) अवस्था में समाप्त हुआ । मुझे नहीं पता कि यह वास्तव में कैसे हुआ, लेकिन यह साथ मारने योग्य नहीं था ।CtrlCTSIGKILL
छोटी कहानी, मैं इसे मारने में सफल रहा gdb:
gdb -p <PID>
> kill
Kill the program being debugged? (y or n) y
> quit
गिल्स के उत्तर से मिले सुराग के आधार पर, मैंने एक प्रक्रिया "Z" को शीर्ष पर ( <defunct>ps में) चिह्नित किया था जो सिस्टम संसाधनों का उपयोग कर रहा था, इसमें एक पोर्ट भी खुला था जो LISTEN'ing था और आप उस पोर्ट से कनेक्ट कर सकते थे। यह उस पर अमल करने के बाद था kill -9। इसके माता-पिता "1" थे ( initइसलिए) सैद्धांतिक रूप से इसे केवल दोहराया जाना चाहिए और गायब हो जाना चाहिए। लेकिन यह नहीं था, यह चारों ओर चिपका हुआ था, हालांकि नहीं चल रहा था, और "मर नहीं रहा"
तो मेरे मामले में यह ज़ोंबी था, लेकिन अभी भी संसाधनों का उपभोग ... FWIW।
और यह के किसी भी संख्या से killable नहीं था kill -9की
और इसके माता-पिता थे, initलेकिन इसे साफ नहीं किया गया था। Ie initएक ज़ोंबी बच्चा था।
और समस्या को ठीक करने के लिए रीबूट आवश्यक नहीं था। हालांकि एक रिबूट ने समस्या के आसपास "काम किया होगा" और इसे तेजी से बंद कर दिया। बस इनायत नहीं, जो अभी भी संभव थी।
और यह एक ज़ोंबी प्रक्रिया के स्वामित्व वाला एक लिस्टेन बंदरगाह था (और कुछ अन्य बंदरगाहों जैसे CLOSE_WAIT स्थिति में लोकलहोस्ट से लोकलहोस्ट जुड़ा हुआ)। और यह अभी भी कनेक्शन स्वीकार किए जाते हैं। यहां तक कि एक ज़ोंबी के रूप में। मुझे लगता है कि यह बंदरगाहों को साफ करने के लिए चारों ओर नहीं पहुंची थी, लेकिन अभी तक आने वाले कनेक्शन को अभी भी टीसीपी सुनने वाले बंदरगाह के बैकलॉग में जोड़ा गया था, हालांकि उनके पास स्वीकार किए जाने का कोई मौका नहीं था।
उपरोक्त में से कई इंटरव्यू में विभिन्न स्थानों पर "असंभव" बताए गए हैं।
यह बताता है कि मेरे भीतर एक आंतरिक धागा था जो "सिस्टम कॉल" (इस उदाहरण में ioctl) को निष्पादित कर रहा था जो कि लौटने में कुछ घंटे लग रहे थे (यह अपेक्षित व्यवहार था)। जाहिरा तौर पर सिस्टम "सभी तरह से" प्रक्रिया को नहीं मार सकता है जब तक ioctlकि यह कॉल से वापस नहीं आता है , अनुमान है कि यह कर्नेल भूमि में प्रवेश करता है। कुछ घंटों के बाद यह वापस आ गया, चीजें साफ हो गईं और उम्मीद के मुताबिक कुर्सियां अपने आप बंद हो गईं, आदि। कि मौत की पंक्ति पर कुछ सुस्त समय है! कर्नेल धैर्यपूर्वक इसे मारने के लिए इंतजार कर रहा था।
तो ओपी को जवाब देने के लिए, कभी-कभी आपको इंतजार करना पड़ता है। एक लम्बा समय। फिर मार आखिरकार लगेगा।
यह भी देखने के लिए dmesg जांचें कि क्या कर्नेल पैनिक (यानी कर्नेल बग) था।