VPN के साथ जागने के बाद Mac फ्रीज़ हो जाता है: क्या दर्ज करें

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

क्या जवाब देना बंद हुआ, और क्या सिर्फ़ इंतज़ार करना बंद हुआ

सबसे सस्ते परीक्षणों से शुरू करें: पॉइंटर हिलाएँ और किसी स्थानीय टेक्स्ट फ़ील्ड में टाइप करें, क्लाइंट का अपना स्टेटस व्यू खोलें और वह स्थिति पढ़ें जो वह बताता है, फिर पहले से खुले सत्र को फिर से शुरू करने के बजाय निजी ऐप में नया ऑपरेशन शुरू करें। बाकी कुछ भी छूने से पहले तीनों जवाब लिख लें, क्योंकि क्या विफल हुआ इसका क्रम पहला विवरण है जो लोग भूल जाते हैं।

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

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

ऐसी समयरेखा जिसे कल भी आप बचा सकें

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

pmset -g log | grep -i -E 'wake|sleep'
log show --last 15m --predicate 'process == "<client-process>"' --style compact

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

लक्षण से मेल खाता कैप्चर चुनें

Apple Activity Monitor की डायग्नोस्टिक्स गाइड में तीन कैप्चर लिखता है, और वे अलग सवालों के जवाब देते हैं। Sample Process एक चुनी हुई प्रोसेस को तीन सेकंड देखता है, spindump उस ऐप को निशाना बनाता है जिसने जवाब देना बंद कर दिया है और जिसे अब ज़बरदस्ती बंद किया जाएगा, और System Diagnostics सिस्टम लॉग को एक बंडल में इकट्ठा करता है।

आदत के बजाय जो आपने देखा उसके आधार पर चुनें। चलता है पर गलत बर्ताव करता है ऐसा क्लाइंट sample पाता है, जो sample <pid> 3 -file ~/Desktop/sample.txt से या गियर मेन्यू से लिया जाता है। जो ऐप अनंत घूमता है और जिसे मारना पड़ता है, वह उसी मेन्यू से Spindump आइटम पाता है। जो समस्या क्लाइंट और सिस्टम दोनों को छूती है उसे sudo sysdiagnose -f ~/Desktop मिलता है। जहाँ हो सके ज़बरदस्ती बंद करने से पहले sample लें, क्योंकि बंद करना ठीक उसी स्थिति को नष्ट करता है जिसे आप देखना चाहते थे, और फ़ाइल का नाम कारण के अपने अनुमान के बजाय घटना और समय पर रखें।

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

जब पॉइंटर ख़ुद न हिले

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

जब मशीन वापस आए, तो इस नतीजे का विरोध करें कि रीस्टार्ट ने दोषी ढूँढ लिया। उसने सेवा बहाल की और कुछ नाम नहीं लिया। सिर्फ़ एक नियंत्रित बदलाव के साथ दोहराव ही किसी घटक की ओर इशारा कर सकता है।

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

एक घटना सौंपें, मिज़ाज नहीं

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

अच्छा रिकॉर्ड यह भी बताता है कि आपने पहले से क्या बाहर रखा है। अगर फ्रीज़ के दौरान कोई स्थानीय ऐप जवाब दे रहा था, तो बताएं; अगर स्लीप लॉग लॉक के बजाय असली जागना दिखाता है, तो वह भी बताएं। अगले व्यक्ति को आपके किए हुए परीक्षण दोहराने न पड़ें।

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