Mac, VPN ile uyandıktan sonra donuyor: ne kaydedilmeli
Uyanma sonrası donma tüm masaüstü, istemci veya bekleyen tek bir uygulama olabilir. Neyin başarısız olduğunu belirleyin, sonra o belirtiye uyan raporu alın.
Uyandıktan sonra donan bir Mac hakkındaki raporlar genellikle üç hatayı tek bir şikâyette birleştirir. VPN istemcisi tıklamaları yok sayarken imleç hâlâ hareket edebilir, bir uzak oturum sona ererken istemci çalışabilir veya tüm masaüstü giriş almayı bırakabilir. Bunların her biri farklı kanıt gerektirir ve donmanın ardından gelen ilk dakika hangisine baktığınızı belirler. Yanlış tahmin, sonraki her adımı yanlış yöne gönderir.
Neyin yanıt vermeyi bıraktığı ve neyin yalnızca beklemeyi bıraktığı
En ucuz testlerle başlayın: imleci hareket ettirip yerel bir metin alanına yazın, istemcinin kendi durum görünümünü açıp bildirdiği durumu okuyun, ardından zaten açık olan oturumu sürdürmek yerine özel uygulamada yeni bir işlem başlatın. Başka bir şeye dokunmadan önce üç yanıtı yazın, çünkü neyin başarısız olduğu sırası insanların ilk unuttuğu ayrıntıdır.
Her sonuç başka bir yeri gösterir. Tek bir takılı oturum kanıtı tünelin diğer tarafına koyar ve Mac yalnızca izleyicidir. Masaüstü hâlâ çalışırken tıklamaları yok sayan istemci, aramayı o sürece ve günlüğüne daraltır. İmleci yok sayan makine, herhangi bir şeyi çalıştırma seçeneğini ortadan kaldırır, çünkü her inceleme komutu yanıt veren bir kabuk gerektirir.
Kullanıcı tek cümleyle anlatsa bile üç durumu ayrı tutun. Verdiğiniz rapor hangi testin önce başarısız olduğunu ve hangilerinin hâlâ geçtiğini söylemeli, makinenin donduğunu değil. Bu ayrım, destek mühendisinin ağa, istemciye veya donanıma bakmaya karar vermesini sağlar.
Yarın da savunabileceğiniz bir zaman çizelgesi
Saat, kaydın daha sonra yeniden oluşturulamayan parçasıdır. Kapağın ne zaman açıldığını veya makinenin ne zaman uyandığını, ilk başarısız eylemin ne zaman gerçekleştiğini ve bu iki anın saniyeler mi dakikalar mı arayla olduğunu not edin. Sonra Mac'in gerçekten uyuyup uyumadığını yoksa yalnızca ekranı mı kilitlediğini yazın, çünkü bunlar farklı uyanma yolları olan farklı durumlardır. Uyku günlüğü o zaman çizelgesinin sonradan kontrol edebileceğiniz tek parçasıdır.
pmset -g log | grep -i -E 'wake|sleep'
log show --last 15m --predicate 'process == "<client-process>"' --style compactİlk komut belirsiz bir anıyı ikinciye yazabileceğiniz bir zaman damgasına dönüştürür. Günlük sorgusunu istemci süreciyle ve kısa bir pencereyle sınırlayın, bütün bir gün yerine bir sayfa çıktı alırsınız. Ekran hâlâ önünüzdeyken model tanımlayıcısını, istemci derlemesini ve bulunduğunuz ağı aynı nota kopyalayın; ertesi sabah birleştirilen rapor, onu okunur kılan sırayı kaybeder.
Belirtiye uyan yakalamayı seçin
Apple, Activity Monitor tanılama kılavuzunda üç yakalama belgeler ve bunlar farklı soruları yanıtlar. Sample Process seçilen bir süreci üç saniye izler, spindump yanıt vermeyi bırakmış ve birazdan zorla kapatılacak bir uygulamayı hedefler, System Diagnostics ise sistem günlüklerini bir pakette toplar.
Alışkanlığa göre değil, gözlemlediğinize göre seçin. Çalışan ama kötü davranan istemci bir sample alır; sample <pid> 3 -file ~/Desktop/sample.txt ile veya dişli menüsünden alınır. Sonsuza kadar dönen ve öldürülmesi gereken uygulama aynı menüden Spindump öğesini alır. İstemciyi ve sistemi kapsayan sorun sudo sysdiagnose -f ~/Desktop alır. Mümkünse zorla kapatmadan önce sample alın, çünkü sonlandırma tam olarak incelemek istediğiniz durumu yok eder; dosyayı nedenle ilgili tahmininize göre değil olaya ve saate göre adlandırın.
Her paketi hassas olarak değerlendirin. Bu raporlar hesap adları, ana bilgisayar adları, yollar ve ağ ayrıntıları taşır; bu yüzden bunları herkese açık bir başlığa eklemek yerine kuruluşunuzun kullandığı destek kanalından gönderin. Bir raporun kısaltılması gerekiyorsa bir kopyasını kısaltın ve aslını bozmadan bırakın.
İmlecin kendisi hareket etmediğinde
Ölü arayüz işlemlerin sırasını değiştirir. Yanıt vermeyen bir kabuktan süreç örnekleyemez veya sorgu çalıştıramazsınız, bu nedenle ilk hedef kurtarma, ikincisi kayıttır. Zorla yeniden başlatma bazen tek çıkış yoludur ve en yararlı ayrıntıların kaybolduğu an da odur. Saatı, açık pencereleri ve yeniden başlatmadan önce ağ menüsünün bağlantı gösterip göstermediğini not edin; süreç durumu kalmasa da bu gözlemler yeniden başlatmayı atlatır.
Makine geri geldiğinde, yeniden başlatmanın suçluyu bulduğu sonucuna direnin. Hizmeti geri getirdi ve hiçbir şey adlandırmadı. Yalnızca tek kontrollü değişiklikle yapılan bir yineleme bir bileşene işaret edebilir.
Donma geri gelirse her denemede tek koşulu değiştirin: ağ, istemci sürümü veya uyku modu. Önce uzak çalışmayı kaydedin ve üretim makinesinde zorunlu uykuyu tekrarlamaktan kaçının, çünkü yinelenen sert döngüler veri kaybı riski taşır ve çoğu zaman peşinde olduğunuzdan farklı bir hata üretir. Her denemeyi koşullarıyla yazın, böylece bir sonraki anekdot değil karşılaştırılabilir olsun.
Bir olay teslim edin, bir ruh hâli değil
Eyleme yol açan teslim dört şeyi adlandırır: neyin yanıt vermeyi bıraktığı, ne zaman olduğu, o anda ağın nasıl göründüğü ve hangi yakalamanın o pencereyi kapsadığı. İstemci sürümünü ve macOS derlemesini ekleyin, sonra durun. Platform ekibi de istemci tedarikçisi de o cümleye göre hareket edebilir ve hiçbiri hayal kırıklığı betimlemesine göre hareket edemez. Kaydı tek yerde tutun ve her seferinde hikâyeyi yeniden anlatmak yerine ona ekleyin; bir güncelleme davranışı değiştirdiyse hangisi olduğunu not edin, çünkü o da kanıttır.
İyi bir kayıt neyi zaten dışladığınızı da söyler. Donma sırasında yerel bir uygulama yanıt verdiyse bunu söyleyin; uyku günlüğü kilit değil gerçek bir uyanma gösteriyorsa onu da söyleyin. Bir sonraki kişi zaten yaptığınız testleri tekrarlamak zorunda kalmamalı.
Bileti kapatmadan önce üç şeyi kontrol edin: zaman damgası bellekten değil uyku günlüğünden geliyor, yakalama gerçekten gördüğünüz belirtiye uyuyor ve paket onaylanmış konumda duruyor. Üçünden biri eksikse rapor gönderilmeye hazır değildir.