ה-Mac קופא אחרי התעוררות עם VPN: מה לתעד

דוחות על Mac קפוא אחרי התעוררות ממזגים לעיתים קרובות שלושה כשלים לתלונה אחת. הסמן עשוי עדיין לזוז בזמן שלקוח ה-VPN מתעלם מקליקים, הלקוח עשוי לעבוד בזמן שסשן מרוחק אחד פג, או שכל שולחן העבודה עשוי להפסיק לקבל קלט. כל אחד מאלה צריך ראיות שונות, והדקה הראשונה אחרי הקיפאון קובעת איזה מהם יש לפניכם. ניחוש שגוי שולח כל צעד מאוחר יותר בכיוון הלא נכון.

מה הפסיק לענות, ומה רק הפסיק לחכות

התחילו בבדיקות הזולות ביותר: הזיזו את הסמן והקלידו בשדה טקסט מקומי, פתחו את תצוגת המצב של הלקוח וקראו את המצב שהוא מדווח, ואז התחילו פעולה חדשה באפליקציה הפרטית במקום לחדש את הסשן שכבר היה פתוח. רשמו את שלוש התשובות לפני שתגעו במשהו אחר, כי סדר מה שנכשל הוא הפרט הראשון שאנשים שוכחים.

כל תוצאה מצביעה למקום אחר. סשן אחד תקוע שם את הראיה בצד השני של המנהרה, וה-Mac הוא רק צופה. לקוח שמתעלם מקליקים בזמן ששולחן העבודה עדיין עובד מצמצם את החיפוש לתהליך הזה וללוג שלו. מכונה שמתעלמת מהסמן מסירה את האפשרות להריץ משהו בכלל, כי כל פקודת בדיקה צריכה מעטפת שמגיבה.

שמרו על שלושת המקרים בנפרד גם כשהמשתמש מתאר אותם במשפט אחד. הדוח שאתם מגישים צריך לומר איזו בדיקה נכשלה ראשונה ואילו עדיין עברו, לא שהמכונה קפאה. ההבחנה הזו היא מה שמאפשר למהנדס תמיכה להחליט אם להסתכל על הרשת, על הלקוח או על החומרה.

ציר זמן שתוכלו עדיין להגן עליו מחר

השעון הוא החלק בתיעוד שאי אפשר לשחזר אחר כך. רשמו מתי נפתח המכסה או התעוררה המכונה, מתי קרתה הפעולה הכושלת הראשונה, והאם שני הרגעים היו במרחק שניות או דקות. ואז כתבו אם ה-Mac באמת ישן או רק נעל את המסך, כי אלה מצבים שונים עם נתיבי התעוררות שונים. יומן השינה הוא החלק היחיד בציר הזמן הזה שתוכלו לבדוק אחר כך.

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

הפקודה הראשונה הופכת זיכרון מעורפל לחותמת זמן שתוכלו להקליד בשנייה. הגבילו את שאילתת היומן לתהליך הלקוח ולחלון קצר, ותקבלו עמוד פלט במקום יום שלם. העתיקו את מזהה הדגם, גרסת הלקוח והרשת שהייתם עליה לאותה הערה בזמן שהמסך עוד לפניכם; דוח שנבנה למחרת בבוקר מאבד את הסדר שהפך אותו לקריא.

בחרו את הלכידה שמתאימה לתסמין

אפל מתעדת שלוש לכידות במדריך האבחון של Activity Monitor, והן עונות על שאלות שונות. Sample Process צופה בתהליך נבחר אחד במשך שלוש שניות, spindump מכוון לאפליקציה שהפסיקה להגיב ועומדת להיות סגורה בכפייה, ו-System Diagnostics אוסף יומני מערכת לחבילה.

בחרו לפי מה שצפיתם, לא לפי הרגל. לקוח שרץ אבל מתנהג רע מקבל sample, שנלקח עם sample <pid> 3 -file ~/Desktop/sample.txt או מתפריט גלגל השיניים. אפליקציה שמסתובבת לנצח וצריך להרוג אותה מקבלת את פריט Spindump מאותו תפריט. בעיה שמכסה את הלקוח והמערכת מקבלת sudo sysdiagnose -f ~/Desktop. קחו sample לפני סגירה כפויה כשאפשר, כי הפסקה הורגת בדיוק את המצב שרציתם לבדוק, ותנו לקובץ שם לפי האירוע והשעה ולא לפי הניחוש שלכם לגבי הסיבה.

התייחסו לכל חבילה כאל רגישה. הדוחות האלה נושאים שמות חשבונות, שמות מארח, נתיבים ופרטי רשת, אז שלחו אותם בערוץ התמיכה שהארגון שלכם משתמש בו במקום לצרף אותם לשרשור ציבורי. אם צריך לקצר דוח, קצרו עותק והשאירו את המקור שלם.

כשהסמן עצמו לא זז

ממשק מת משנה את סדר הפעולות. אינכם יכולים לקחת sample של תהליך או להריץ שאילתה ממעטפת שלא מגיבה, אז המטרה הראשונה היא התאוששות והשנייה היא תיעוד. הפעלה מחדש בכפייה היא לפעמים הדרך היחידה החוצה, והיא גם הרגע שבו הפרטים השימושיים ביותר נעלמים. רשמו את השעה, את החלונות שהיו פתוחים והאם תפריט הרשת הראה חיבור לפני ההפעלה מחדש; התצפיות האלה שורדות את האתחול גם אם מצב התהליך לא שורד.

כשהמכונה חוזרת, התנגדו למסקנה שההפעלה מחדש מצאה את האשם. היא החזירה את השירות ולא שמה דבר. רק חזרה עם שינוי מבוקר אחד יכולה להצביע על רכיב.

אם הקיפאון חוזר, שנו תנאי אחד בכל ניסיון: הרשת, גרסת הלקוח או מצב השינה. שמרו קודם עבודה מרחוק, והימנעו מלולאה של שינה כפויה על מכונת ייצור, כי מחזורים קשיחים חוזרים מסתכנים באובדן נתונים ולעיתים קרובות מייצרים כשל אחר מזה שאתם רודפים אחריו. רשמו כל ניסיון עם תנאיו כדי שהבא יהיה בר-השוואה ולא אנקדוטה.

מסרו אירוע אחד, לא מצב רוח

המסירה שמניעה פעולה נוקבת בארבעה דברים: מה הפסיק להגיב, מתי זה קרה, איך נראתה הרשת באותו רגע, ואיזו לכידה מכסה את החלון. הוסיפו את גרסת הלקוח ואת גרסת macOS, ואז עצרו. גם צוות הפלטפורמה וגם ספק הלקוח יכולים לפעול לפי המשפט הזה, ואף אחד מהם לא יכול לפעול לפי תיאור של תסכול. שמרו את התיעוד במקום אחד והוסיפו לו במקום לספר את הסיפור מחדש בכל פעם; אם עדכון שינה את ההתנהגות, ציינו איזה, כי גם זו ראיה.

תיעוד טוב אומר גם מה כבר שללתם. אם אפליקציה מקומית הגיבה בזמן הקיפאון, אמרו זאת; אם יומן השינה מראה התעוררות אמיתית ולא נעילה, אמרו גם את זה. האדם הבא לא אמור לחזור על בדיקות שכבר עשיתם.

לפני שתסגרו את הפנייה, בדקו שלושה דברים: חותמת הזמן מגיעה מיומן השינה ולא מהזיכרון, הלכידה מתאימה לתסמין שראיתם באמת, והחבילה נמצאת במקום המאושר. אם אחד מהשלושה חסר, הדוח לא מוכן לשליחה.