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 बिल्ड जोडा, मग थांबा। प्लॅटफॉर्म टीम आणि क्लायंट विक्रेता दोघेही त्या वाक्यावर काम करू शकतात, आणि निराशेच्या वर्णनावर कोणीही काम करू शकत नाही। नोंद एकाच ठिकाणी ठेवा आणि प्रत्येक वेळी कथा पुन्हा सांगण्याऐवजी तिला भर घाला; अपडेटने वर्तन बदलले असेल तर कोणते ते नोंदवा, कारण तेही पुरावा आहे।

चांगली नोंद तुम्ही आधीच काय वगळले हेही सांगते। गोठण्याच्या वेळी स्थानिक ॲपने उत्तर दिले असेल तर सांगा; झोपेचा लॉग लॉकऐवजी खरे जागणे दाखवत असेल तर तेही सांगा। पुढच्या व्यक्तीला तुम्ही आधीच केलेल्या चाचण्या पुन्हा करावी लागू नयेत।

तिकीट बंद करण्यापूर्वी तीन गोष्टी तपासा: वेळमुद्रांक स्मरणातून नाही तर झोपेच्या लॉगमधून येतो, कॅप्चर तुम्ही खरोखर पाहिलेल्या लक्षणाशी जुळते, आणि बंडल मंजूर जागी आहे। तीनपैकी एखादी गोष्ट नसेल तर अहवाल पाठवायला तयार नाही।