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 <pid> 3 -file ~/Desktop/sample.txt または歯車メニューから sample を取ります。延々と回り続けて殺す必要があるアプリには、同じメニューの Spindump 項目を使います。クライアントとシステムの両方にまたがる問題には sudo sysdiagnose -f ~/Desktop を使います。可能なら強制終了の前に sample を取ってください、終了は見たかった状態そのものを壊すので、ファイル名は原因の推測ではなく出来事と時刻にします。

どのバンドルも機密として扱ってください。これらのレポートにはアカウント名、ホスト名、パス、ネットワークの詳細が含まれるため、公開スレッドに添付せず、組織が使うサポート経路で送ってください。レポートを削る必要がある場合は、コピーを削り、原本はそのまま残してください。

ポインタ自体が動かないとき

死んだインターフェースは作業の順序を変えます。応答しないシェルからプロセスをサンプリングしたり問い合わせを実行したりはできないので、最初の目的は復旧、次が記録です。強制再起動が唯一の出口になることがあり、それは最も有用な詳細が消える瞬間でもあります。再起動の前に、時刻、開いていたウィンドウ、ネットワークメニューに接続が表示されていたかを記録してください、プロセスの状態は残らなくてもその観察は再起動を越えて残るからです。

マシンが戻ったら、再起動で原因が見つかったという結論に抗ってください。再起動はサービスを戻しただけで、何も名指ししていません。一つの統制された変更を加えた再現だけが、コンポーネントを指し示せます。

フリーズが再発するなら、試行ごとにネットワーク、クライアントのバージョン、スリープモードのうち一つだけを変えます。まずリモートの作業を保存し、本番機で強制スリープを繰り返さないでください、繰り返すハードな循環はデータ損失の危険があり、追っている不具合とは別の不具合を生みがちだからです。各試行を条件とともに記録し、次を逸話ではなく比較可能なものにしてください。

気分ではなく一つの出来事を引き継ぐ

行動につながる引き継ぎは、何が応答をやめたか、いつ起きたか、その瞬間のネットワークの状態、どのキャプチャがその時間枠を覆うかの四つを名指しします。クライアントのバージョンと macOS のビルドを加えて、そこで止めます。プラットフォームチームもクライアントのベンダーもその一文で動けますが、いらだちの描写ではどちらも動けません。記録は一か所に置き、毎回話をやり直すのではなく追記してください、アップデートが挙動を変えたならどれかを書いてください、それも証拠だからです。

よい記録は、すでに除外したことも書きます。フリーズ中にローカルアプリが応答していたならそう書き、スリープログがロックではなく本当の起床を示すならそれも書きます。次の人が、すでに行ったテストをやり直さずに済むようにしてください。

チケットを閉じる前に、タイムスタンプが記憶ではなくスリープログから来ていること、キャプチャが実際に見た症状と合っていること、バンドルが承認された場所にあることの三つを確認します。どれかが欠けていれば、そのレポートは送れる状態ではありません。