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 बिल्ड थप्नुहोस्, त्यसपछि रोक्नुहोस्। प्लेटफर्म टिम र क्लाइन्ट विक्रेता दुवैले त्यो वाक्यमा काम गर्न सक्छन्, र निराशाको वर्णनमा कसैले पनि काम गर्न सक्दैन। रेकर्डलाई एकै ठाउँमा राख्नुहोस् र हरेक पटक कथा फेरि भन्नुको सट्टा त्यसमा थप्नुहोस्; अपडेटले व्यवहार बदल्यो भने कुन हो लेख्नुहोस्, किनकि त्यो पनि प्रमाण हो।

राम्रो रेकर्डले तपाईंले पहिले नै के बहिष्कृत गर्नुभयो पनि बताउँछ। जम्ने क्रममा स्थानीय एपले जवाफ दिएको थियो भने भन्नुहोस्; निद्राको लगले लकको सट्टा साँचो उठ्ने देखाएको भए त्यो पनि भन्नुहोस्। अर्को व्यक्तिले तपाईंले पहिले नै गरेका परीक्षण दोहोर्याउनु नपर्ने हो।

टिकट बन्द गर्नुअघि तीन कुरा जाँच्नुहोस्: समयछाप सम्झनाबाट होइन निद्राको लगबाट आउँछ, क्याप्चर तपाईंले साँच्चै देखेको लक्षणसँग मिल्छ, र बन्डल स्वीकृत ठाउँमा छ। तीनमध्ये कुनै एउटा छैन भने रिपोर्ट पठाउन तयार छैन।