ログインはできるのに何も映らないMac

お客様がブラウザでMacを開きます。接続は成功します。ユーザー名とパスワードも通ります。ところが画面は真っ黒です。エラーでも切断でもありません。真っ黒な画面で、マウスカーソルだけが動きます。

どのログを見ても、マシンは正常です。画面共有のサービスは動いています。アカウントの認証も通ります。セッションはロックされていません。ディスク、CPU、メモリも正常です。どこにも問題は報告されていません。

これで当社は数日を失いました。実際の原因は何だったのか。そして、それを確かめる自然な方法が役に立たないどころか有害なのはなぜか。それを説明します。

思いつく原因はすべて外れ

画面が真っ黒なヘッドレスMacには、おなじみの容疑者リストがあります。当社はそのすべてを確認しました。

• ディスプレイが接続されていない。よくある助言は、ダミーのHDMIプラグを使うことです。購入して試しましたが、変化はありませんでした。
• 解像度。ヘッドレスのMacは、一部のクライアントが苦手とする解像度で起動することがあります。これも原因ではありませんでした。
• 画面ロック。ロックされたセッションは黒い画面を返すことがあります。しかしセッションはロックされていませんでした。
• ディスプレイそのもの。本物のMac miniに本物のモニターをつなぎました。物理的な画面も真っ黒でした。

この最後の結果で、調査の方向が変わりました。マシンはリモートのクライアントに映像を送れていなかったのではありません。そもそも映像がなかったのです。

動いていることと許可されていることは別

当社のプロビジョニングスクリプトは、人がいなくても使える唯一の方法で画面共有をオンにしています。

launchctl enable system/com.apple.screensharing
launchctl bootstrap system   /System/Library/LaunchDaemons/com.apple.screensharing.plist

これでサービスは起動します。macOS 14以降、Apple純正のkickstart -activateはヘッドレスでは動作を拒否します。残る方法はこれしかありません。

しかし、サービスを起動することと、画面収録の権限を与えることは別です。画面収録はTCCの権限です。macOSがこれを与える方法は2つしかありません。人がシステム設定で画面共有をオンにして認証するか、MDMがPPPCプロファイルを配信するかです。

その権限がなくても、サービスは動き続けます。ポート5900で待ち受け、パスワードも受け付けます。ただ、見せることを許されたものが何もないのです。

正しく尋ねれば、macOSはそう教えてくれます。

$ sudo .../ARDAgent.app/Contents/Resources/kickstart     -configure -access -on -users runner -privs -all

Screen recording might be disabled. Screen Sharing or Remote
Management must be enabled from System Settings or via MDM.

もっと早く見つけられなかった理由

ここが伝える価値のある部分です。問題は、答えが隠れていたことではありません。手軽な確認方法がどれも「問題なし」と言っていたことです。

screencaptureをSSH経由で実行すると必ず失敗する。SSHセッションで実行すると、権限が与えられているかどうかに関係なく、TCCが拒否します。壊れたマシンと正常なマシンを区別できないので、得られた結果はすべてノイズでした。

kickstartによる確認は、権限がないときに成功扱いになる。十分な権限がないと、何も出力しません。空の出力を「警告なし」と扱うコードは、それを成功と読みます。当社のコードがまさにそうでした。

どちらの確認にも共通点があります。失敗したときの出力が、成功したときの出力とまったく同じなのです。こうした確認は、弱い証拠ではありません。安心材料のふりをした、証拠ゼロです。

映像そのものを測る

信頼できる唯一のテストは、お客様が見るものを確かめることです。当社は本物のVNCクライアントとして接続し、フレームバッファの矩形を1つ取得して測定します。真っ黒なデスクトップは、明るさがほぼゼロの2色です。正常なデスクトップはそうではありません。

desktop        : Mac mini  1920x1080  32bpp depth24
sampled        : 273768 pixels from 1 rect(s)
mean brightness: 36.31%
distinct colours: 93828
RESULT: REAL PICTURE

9万3千色あれば、それはデスクトップです。2色なら失敗です。解釈の余地はなく、読み違える終了コードもありません。現在は、お客様にマシンを渡す前に、すべてのマシンでこれを実行しています。

直し方とそのコスト

1台だけなら、10秒で直ります。システム設定の「一般」から「共有」を開きます。画面共有をオフにして、もう一度オンにします。管理者パスワードを求められます。この認証こそが肝心な点です。スクリプトがサービスを起動しているので、スイッチはたいてい最初からオンに見えます。それでも切り替えることで、権限が与えられます。

この権限はシステムレベルなので、顧客の入れ替わりでマシンを消去しても残ります。実際に1台を消去して、もう一度確認しました。

本当のコストは、一度だけマシンの前に人が必要なことです。それ以外はスクリプト化された工程の中で、唯一の手作業です。フリート規模での答えは、権限を事前に与えるMDMの構成プロファイルです。これが正しい直し方です。そして、まだ登録していないMacでは、スクリプトで回避できない唯一の点でもあります。

Macを自動化しているなら

持ち帰る価値のあることが2つあります。画面収録に関するものは、そのうち1つだけです。

1つめは、macOSにはスクリプトから届かない種類の状態があることです。TCCの権限は、キーボードの前にいる人か、MDMのプロファイルの後ろに意図的に置かれています。自動化ですべてを設定できると思い込んでいると、いずれ、プロビジョニング済みに見えて実はそうでないマシンができます。

2つめはもっと一般的な話です。確認処理を書く前に、対象が壊れているときに何を出力するかを考えてください。それが正常なときの出力と同じなら、その確認には価値がありません。確認がまったくないより、多くの時間を失います。当社にはそういう確認が2つありました。半日で済むはずの調査に数日かかったのは、そのためです。