Raportoj pri frostinta Mac post vekiĝo ofte kunfandas tri paneojn en unu plendon. La montrilo eble ankoraŭ moviĝas dum la VPN-kliento ignoras klakojn, la kliento eble funkcias dum unu fora sesio eksvalidiĝas, aŭ la tuta labortablo eble ĉesas akcepti enigon. Ĉiu el tiuj bezonas malsamajn pruvojn, kaj la unua minuto post la frostiĝo decidas, kiun vi frontas. Malĝusta konjekto direktas ĉiun postan paŝon en la malĝustan direkton.

Kio ĉesis respondi, kaj kio nur ĉesis atendi

Komencu per la plej malmultekostaj testoj: movu la montrilon kaj tajpu en lokan tekstan kampon, malfermu la propran statan vidon de la kliento kaj legu la staton, kiun ĝi raportas, poste komencu novan operacion en la privata programo anstataŭ daŭrigi la jam malfermitan sesion. Skribu la tri respondojn antaŭ ol tuŝi ion alian, ĉar la ordo de tio, kio malsukcesis, estas la unua detalo, kiun homoj forgesas.

Ĉiu rezulto montras al alia loko. Unu blokita sesio metas la pruvon al la alia flanko de la tunelo, kaj la Mac estas nur observanto. Kliento, kiu ignoras klakojn dum la labortablo ankoraŭ funkcias, mallarĝigas la serĉon al tiu procezo kaj ĝia protokolo. Maŝino, kiu ignoras la montrilon, forigas la eblon lanĉi ion ajn, ĉar ĉiu inspektokomando bezonas ŝelon, kiu respondas.

Tenu la tri kazojn apartaj eĉ kiam la uzanto priskribas ilin per unu frazo. La raporto, kiun vi sendas, devus diri, kiu testo unue malsukcesis kaj kiuj ankoraŭ pasis, ne ke la maŝino frostiĝis. Tiu distingo ebligas al subtena inĝeniero decidi, ĉu rigardi la reton, la klienton aŭ la aparataron.

Templinio, kiun vi povas ankoraŭ defendi morgaŭ

La horloĝo estas la parto de la registro, kiu ne povas esti rekonstruita poste. Notu, kiam malfermiĝis la kovrilo aŭ vekiĝis la maŝino, kiam okazis la unua malsukcesa ago, kaj ĉu tiuj du momentoj estis sekundoj aŭ minutoj dise. Poste skribu, ĉu la Mac vere dormis aŭ nur ŝlosis la ekranon, ĉar tiuj estas malsamaj statoj kun malsamaj vekiĝaj vojoj. La dormprotokolo estas la sola parto de tiu templinio, kiun vi povas kontroli poste.

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

La unua komando transformas nebulan memoron en tempomarkon, kiun vi povas entajpi en la dua. Limigu la protokolan demandon al la klienta procezo kaj mallonga fenestro, kaj vi ricevas paĝon da eligo anstataŭ tutan tagon. Kopiu la modelan identigilon, la klientan konstruon kaj la reton, en kiu vi estis, en la saman noton dum la ekrano ankoraŭ estas antaŭ vi; raporto kunmetita la sekvan matenon perdas la ordon, kiu faris ĝin legebla.

Elektu la kaptaĵon, kiu kongruas kun la simptomo

Apple dokumentas tri kaptaĵojn en la gvidilo pri diagnozoj de Activity Monitor, kaj ili respondas al malsamaj demandoj. Sample Process observas unu elektitan procezon dum tri sekundoj, spindump celas programon, kiu ĉesis respondi kaj baldaŭ estos perforte fermita, kaj System Diagnostics kolektas sistemajn protokolojn en pakaĵon.

Elektu laŭ tio, kion vi observis, ne laŭ kutimo. Kliento, kiu funkcias sed miskondutas, ricevas sample, prenitan per sample <pid> 3 -file ~/Desktop/sample.txt aŭ el la dentrada menuo. Programo, kiu turniĝas eterne kaj devas esti mortigita, ricevas la eron Spindump el tiu sama menuo. Problemo, kiu enhavas la klienton kaj la sistemon, ricevas sudo sysdiagnose -f ~/Desktop. Prenu sample antaŭ ol perforte fermi kiam vi povas, ĉar fermado detruas precize la staton, kiun vi volis inspekti, kaj nomu la dosieron laŭ la okazaĵo kaj la horo anstataŭ laŭ via konjekto pri la kaŭzo.

Traktu ĉiun pakaĵon kiel senteman. Tiuj ĉi raportoj portas kontajn nomojn, gastigantajn nomojn, vojojn kaj retajn detalojn, do sendu ilin per la subtena kanalo, kiun via organizo uzas, anstataŭ aldoni ilin al publika fadeno. Se raporto devas esti mallongigita, mallongigu kopion kaj lasu la originalon sendifekta.

Kiam la montrilo mem ne moviĝas

Mortinta interfaco ŝanĝas la ordon de operacioj. Vi ne povas preni sample de procezo nek lanĉi demandon el ŝelo, kiu ne respondas, do la unua celo estas restarigo kaj la dua estas registro. Perforta restartigo estas foje la sola eliro, kaj ĝi estas ankaŭ la momento, kiam la plej utilaj detaloj malaperas. Notu la horon, la malfermitajn fenestrojn kaj ĉu la reta menuo montris konekton antaŭ ol vi restartigos; tiuj observoj postvivas la restartigon eĉ se la proceza stato ne postvivas.

Post kiam la maŝino revenis, rezistu la konkludon, ke la restartigo trovis la kaŭzanton. Ĝi restarigis la servon kaj nomis nenion. Nur ripeto kun unu kontrolita ŝanĝo povas montri al komponanto.

Se la frostiĝo revenas, ŝanĝu unu kondiĉon per provo: la reton, la klientan version aŭ la dorman reĝimon. Unue konservu foran laboron, kaj evitu ripetadon de perfortaj dormoj sur produktada maŝino, ĉar ripetaj malmolaj cikloj riskas datumperdon kaj ofte produktas alian paneon ol tiu, kiun vi ĉasas. Skribu ĉiun provon kun ĝiaj kondiĉoj, por ke la sekva estu komparebla kaj ne anekdota.

Transdonu unu okazaĵon, ne humoron

La transdono, kiu ricevas agon, nomas kvar aferojn: kio ĉesis respondi, kiam ĝi okazis, kiel la reto aspektis en tiu momento, kaj kiu kaptaĵo kovras la fenestron. Aldonu la klientan version kaj la macOS-konstruon, poste haltu. Kaj la platforma teamo kaj la klienta vendisto povas agi laŭ tiu frazo, kaj neniu povas agi laŭ priskribo de frustriĝo. Tenu la registron en unu loko kaj aldonu al ĝi anstataŭ rekonti la historion ĉiufoje; se ĝisdatigo ŝanĝis la konduton, notu kiun, ĉar ankaŭ tio estas pruvo.

Bona registro ankaŭ diras, kion vi jam ekskludis. Se loka programo respondis dum la frostiĝo, diru tion; se la dormprotokolo montras veran vekiĝon anstataŭ ŝloson, diru ankaŭ tion. La sekva persono ne devus ripeti testojn, kiujn vi jam faris.

Antaŭ ol fermi la bileton, kontrolu tri aferojn: la tempomarko venas el la dormprotokolo, ne el memoro, la kaptaĵo kongruas kun la simptomo, kiun vi efektive vidis, kaj la pakaĵo troviĝas en la aprobita loko. Se iu el la tri mankas, la raporto ne estas preta por sendi.

Rilataj artikoloj