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 બિલ્ડ ઉમેરો, પછી અટકો. પ્લેટફોર્મ ટીમ અને ક્લાયંટ વેન્ડર બંને તે વાક્ય પર કાર્ય કરી શકે છે, અને નિરાશાના વર્ણન પર કોઈ કાર્ય કરી શકતું નથી. રેકોર્ડ એક જગ્યાએ રાખો અને દર વખતે વાર્તા ફરી કહેવાને બદલે તેમાં ઉમેરો; જો અપડેટે વર્તન બદલ્યું હોય, તો કયું તે નોંધો, કારણ કે તે પણ પુરાવો છે.

સારો રેકોર્ડ એ પણ કહે છે કે તમે પહેલેથી શું બાકાત રાખ્યું છે. જો થીજવા દરમિયાન સ્થાનિક એપે જવાબ આપ્યો હોય, તો કહો; જો સૂવાનો લોગ લોકને બદલે સાચું જાગવું દર્શાવે, તો તે પણ કહો. આગળની વ્યક્તિએ તમે પહેલેથી કરેલા પરીક્ષણો ફરી ન કરવા પડે.

ટિકિટ બંધ કરતા પહેલા ત્રણ વસ્તુઓ તપાસો: સમયછાપ યાદશક્તિમાંથી નહીં, સૂવાના લોગમાંથી આવે છે, કેપ્ચર તમે ખરેખર જોયેલા લક્ષણ સાથે મેળ ખાય છે, અને બંડલ મંજૂર જગ્યાએ છે. જો ત્રણમાંથી કોઈ એક પણ ન હોય, તો રિપોર્ટ મોકલવા તૈયાર નથી.