Mac зависає після пробудження з VPN: що записати

Повідомлення про завислий 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, а потім зупиніться. І команда платформи, і постачальник клієнта можуть діяти за цим реченням, і жоден із них не може діяти за описом роздратування. Тримайте запис в одному місці й доповнюйте його, а не переказуйте історію щоразу; якщо оновлення змінило поведінку, вкажіть яке, бо це теж доказ.

Добрий запис також каже, що ви вже виключили. Якщо локальна програма відповідала під час зависання, скажіть це; якщо журнал сну показує справжнє пробудження, а не блокування, скажіть і це. Наступній людині не доведеться повторювати перевірки, які ви вже зробили.

Перед закриттям заявки перевірте три речі: позначка часу береться з журналу сну, а не з пам'яті, знімок відповідає симптому, який ви справді бачили, і пакет лежить у затвердженому місці. Якщо бракує бодай однієї з трьох, звіт не готовий до надсилання.