प्रक्रिया मारने से पहले Mac VPN हेल्पर को पहचानें

पहले से चल रहे हेल्पर के बारे में संदेश को जीवनचक्र का संकेत मानें, प्रक्रियाएँ मारना शुरू करने की अनुमति नहीं। ख़तरनाक क़दम मारना नहीं, बल्कि उससे पहले की पहचान है, क्योंकि एक ही Mac पर एक जैसे नामों वाले कई घटक हो सकते हैं और उनमें से सिर्फ़ एक ही कनेक्शन का मालिक होता है। पहले पहचान का रिकॉर्ड बनाएँ। फिर तय करें कि मारना सही कार्रवाई है भी या नहीं।

कार्रवाई से पहले पहचान का रिकॉर्ड बनाएँ

चार तथ्य किसी प्रक्रिया को पहचानने योग्य बनाते हैं: मौजूदा PID और उसका शुरू होने का समय, वह निष्पादन-योग्य फ़ाइल और उत्पाद जिसका वह हिस्सा है, वह उपयोगकर्ता या विशेषाधिकार संदर्भ जिसके अंतर्गत वह चलती है, और जो भी उसे शुरू करता है। ps -o pid,ppid,user,etime,command -p 1234 पहले तीन एक पंक्ति में देता है, जिसमें यह भी शामिल है कि प्रक्रिया कितने समय से जीवित है। Activity Monitor वही जानकारी अधिक मैत्रीपूर्ण रूप में दिखाता है। नियंत्रक जोड़ें, यानी वह एप्लिकेशन या सेवा जो उसे शुरू और बंद करने के लिए ज़िम्मेदार है। इन चारों के साथ प्रक्रिया एक नाम होना छोड़ देती है और ऐसी वस्तु बन जाती है जिस पर आप सोच-विचार कर सकते हैं।

अगर चारों में से कोई एक अज्ञात है, तो वहीं रुकें। अज्ञात घटक प्रकाशक या व्यवस्थापक के लिए प्रश्न है, प्रयोग नहीं।

पुराने लॉग में मौजूद PID अब किसी और का है

प्रक्रिया ID दोबारा इस्तेमाल होती हैं, और कल के लॉग से कॉपी किया गया नंबर अब पूरी तरह असंबंधित किसी चीज़ की ओर इशारा कर सकता है। कोई भी निष्कर्ष निकालने से पहले शुरू होने के समय की तुलना लॉग के टाइमस्टैम्प से करें। यही बात छोटे नाम पर भी लागू होती है: एक ही उत्पाद के दो बिल्ड एक जैसे नामों और अलग उद्देश्यों वाले हेल्पर भेज सकते हैं। पहचान ट्यूपल है, कभी अकेला नंबर नहीं।

कुछ और छूने से पहले भूमिकाओं को अलग करें। एक ही कनेक्शन का क्लाइंट, कई एप्लिकेशनों को सेवा देने वाला साझा हेल्पर, और दूसरों के सत्र स्वीकार करने वाला सर्वर—सभी सूची में पृष्ठभूमि प्रक्रिया जैसे दिखते हैं। इनमें से सिर्फ़ एक को ही उन परिणामों के बिना रोका जा सकता है जिन पर आपने विचार नहीं किया।

सिग्नल से नहीं, मालिक के ज़रिए रोकें

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

देखें कि बाद में क्या बचता है। मेमोरी में रहने वाली प्रक्रिया शायद अगले कनेक्शन का इंतज़ार कर रही है, जो विफल रोकना नहीं बल्कि डिज़ाइन का चुनाव है।

सुपरवाइज़र आपके मारे हुए को दोबारा क्यों शुरू करता है

अगर कोई लॉन्च डेमन या ऑटो-कनेक्ट नीति चाहती है कि टनल चालू रहे, तो प्रक्रिया मारने से कुछ व्यक्त नहीं होता। सुपरवाइज़र निकास देखता है और उसे फिर शुरू कर देता है, कभी-कभी आपके लॉग पढ़ना ख़त्म करने से पहले ही।

सुपरवाइज़र से लड़ने से पहले उसे ढूँढ़ें। launchctl list लोड की गई जॉब और उनके लेबल दिखाता है, और जीवित रखने की सेटिंग वाली जॉब डिज़ाइन के अनुसार निकास पर फिर शुरू होती है। वहाँ सही कार्रवाई मंशा बदलना है: जॉब अनलोड करें, ऑटो-कनेक्ट नीति बंद करें, या व्यवस्थापक से ऐसा करने को कहें। ज़ोर से बंद करना अलग अर्थ वाला अलग औज़ार है, और वह अटकी हुई प्रक्रिया के लिए दस्तावेज़ी पुनर्प्राप्ति प्रक्रिया का हिस्सा है, नियमित कनेक्शन प्रबंधन का नहीं।

मारना नहीं, जीवनचक्र की घटना दर्ज करें

घटक की पहचान, क्लाइंट का संस्करण, पहली प्रासंगिक जीवनचक्र घटना, और आपने क्या किया—लिख लें। घटना कार्रवाई से अधिक मायने रखती है, क्योंकि लॉगिन पर दो इंस्टेंस दिखना स्टार्टअप क्रम की समस्या है जो दोहराई जाएगी। निष्पादन-योग्य फ़ाइल और उसके नियंत्रक का नाम बताने वाला रिकॉर्ड अगले व्यक्ति को उसे दोबारा बनाने देता है।

फिर इच्छित स्थिति जाँचें: वह सेवा जिसकी उपयोगकर्ता को ज़रूरत थी, और वह निजी संसाधन जिस तक वह पहुँचती है। उस पाइपलाइन से बचें जो उप-स्ट्रिंग खोजकर हर मेल को ज़ोर से मार देती है, क्योंकि वह ऊपर का सब कुछ छोड़ देती है और आमतौर पर इस बात का सबूत नष्ट कर देती है कि दो इंस्टेंस क्यों थे। अगर प्रक्रिया बार-बार लौटती है, तो निष्कर्ष कॉन्फ़िगरेशन या क्रम का दोष है, और सुधार क्लाइंट के स्टार्टअप व्यवहार के मालिक का है।