GPUドライバ更新後に監視が止まった11時間48分と再起動承認

更新の記録は何事もなく完了していました。しかし、GPUの状態を読む処理は止まり、外部の死活監視サービスへの生存報告は黙ったままでした。

2026年7月25日、最後の生存報告は06:03:01でした。17:51:01に復帰するまで、停止時間は約11時間48分です。監視サービスはDOWNを正しく記録していましたが、その状態を人間へ届ける通知先が、この項目にだけ結び付いていませんでした。

これは、自宅ラボをゲーム機としても使う人にとって、単なるGPU障害の話ではありません。更新で再起動が必要になっても、作業中かもしれない機器を自動で止めてよいとは限りません。今回の区切りは「すべてが動いた」ことではなく、「1操作で止められ、止めてよいかを持ち主へ聞ける」状態を用意できたことです。

何が止まったのか

06:03:19、OSの無人更新がGPUドライバを595.71.05から595.84へ更新しました。カーネルに読み込まれていたモジュールは595.71.05のまま、ユーザー空間側のライブラリだけが595.84になりました。この版ズレにより、GPUの状態を読む処理が失敗しました。

生存報告の送信も、その処理の一つでした。表示上は異常が目立たないまま、実質的には次の三つが同時に崩れていました。

壊れていることと、壊れて見えることは別です。これは移設の初回で扱った、移設元が静かに壊れた記録とも同じ方向を向いています。処理の存在だけでは実際の動作を保証できませんでした。

11時間気付けなかった理由

今回、監視サービスは停止を見逃していません。生存報告が来なくなった時点でDOWNとして記録していました。欠けていたのは、DOWNを人間へ伝える通知先です。

同種の監視項目の大半には通知が設定されていた一方、この項目だけが抜けていました。監視対象を追加するときは「監視できるか」だけでなく、「止まったときに誰へ届くか」までを一組として確認する必要があります。

通知が届かなければ、死活監視ダッシュボードに正しい履歴が残っていても、運用上は発見できない停止になります。旧側が動き続けて二重になった移設トラブルでも、表面上の稼働表示だけでは判断できませんでした。監視は、実処理・監視判定・通知経路まで通って初めて役に立ちます。

今回は再起動せずに戻せた

17:50、持ち主の手作業で対象のカーネルモジュールを読み込み直しました。この時点では表示に使うプロセスがなく、対象モジュールの参照カウントも0でした。そのため再起動を伴わずに復旧でき、17:51:01には生存報告がUPへ戻りました。

ただし、これは再起動を不要にする手順ではありません。今回はモジュールを外せる条件が揃っていただけです。次回も同じ条件になるとは限らず、GPUドライバの更新は再起動が必要になる前提で扱うほうが安全です。

再発防止として、無人更新の対象からGPUドライバ関連パッケージを除外しました。以後のドライバ更新は、再起動とセットの手動作業にします。更新を遅らせるためではなく、共有機の停止時刻を持ち主と合わせるためです。

再起動を実行する前に、持ち主へ聞く

この機は同居する持ち主のゲーム機でもあります。そのため、再起動の実行権限があっても、無条件には実行しない構成にしました。

再起動には、人間側のアカウントが発行する一回限りの承認証が必要です。この承認証は自動側では発行できません。「再起動してよいかを伺う操作」と「承認証を消費して実際に再起動する操作」は分かれています。

自動復旧を増やせば便利になる場面はあります。しかし、生活の中で使われる機器では、復旧対象が誰かの作業を止めることもあります。このラボで必要だったのは「壊れたら勝手に直す」ことではなく、止める必要が出たとき、判断を持ち主へ戻せる経路でした。

移設の区切りと、残ったもの

今回の停止は、GPUドライバの版ズレ、電力制限のリセット、実読込を試さない健全性チェック、通知先の設定漏れが重なって見えにくくなりました。復旧後はドライバの版が595.84で一致し、生存報告も戻っています。

一方で、生存報告を実際に送っている処理の実体は、移設で管理しているファイル一式の中に見つかっていません。読み取れない場所にあるとみられますが、何が定期送信しているのかは、まだ特定できていません。

この機は、1操作で止められ、止めてよいかを持ち主に聞ける状態になりました。移設はそこで終わりではありません。次に触るときは、生存報告を送る処理そのものを辿り、管理下へ戻せるかを確かめます。

共有PCでGPUを運用しているなら、次の更新前に「GPUドライバ更新が再起動を伴う手動作業になっているか」と「監視停止の通知先が実際に届くか」を一度だけ確認してください。