自宅ラボ移設で起きた5つの事故と対処——二重ポーリング・Unknown assignment・凍結コピー・空ディレクトリ・GPU監視停止を振り返る

自宅ラボの移設トラブルは、止まった処理だけを探しても拾い切れません。今回の5件を振り返る結論は、移設完了を「新環境で起動した」ではなく、「旧側が止まり、状態・出力・通知まで意図した場所へ届いた」と確認することです。

2026年7月末から8月初めに公開した5件の記録を、公開順にたどります。GPU監視停止の記事は8月2日に公開していますが、扱う停止そのものは7月25日の事象です。本記事は新しい検証を加えず、既存の公開記録を横断して確認先を整理するハブです。

5件の事故を先に比較する

比較すると、確認対象は「プロセスがあるか」から一段ずつ外側へ広がります。旧環境、実行内容、状態の置き場、成果物、通知先までを分けて見ることが、この移設では有効でした。

7月28日公開：新側の起動確認だけでは二重ポーリングを止められない

最初の記録は、スマートプラグを新旧の常駐処理が60秒ごとに問い合わせていた件です。単体では双方とも正常で、障害通知もありませんでした。見つかった契機は通知ではなく棚卸しでした。外部へ作用する処理では、新側の起動と旧側の停止を別々の完了条件にする必要があります。

経緯と停止手順は、スマートプラグを二重ポーリングした移設事故と停止手順にまとめています。

7月29日公開：警告1行で定期処理の本体が動かなかった

次に、移設先のsystemd 259で優先度指定が受け付けられず、警告だけを残して定期処理の本体が起動しない問題が起きました。ログファイルの更新時刻や発火記録だけでは、仕事が実行された証拠になりません。同じ設定を使う処理を一覧化し、1本だけ直して終えないことも重要でした。

39バイトのログから切り分けた内容は、systemd 259のUnknown assignmentで定期処理が起動しない時の切り分けを参照してください。

7月31日公開：凍結コピーは履歴であり、稼働系ではない

監視処理9本では、新環境に移したつもりでも、日付の進まない凍結コピー内のスクリプトを実行し、結果もコピー側へ書いていました。対処は、初回起動時だけコピーから既存状態を読み、新環境の状態として書き切ることです。これにより、ベースラインを失って全件を新規扱いにする誤通知を避ける狙いを置きました。

状態引き継ぎの設計と初回結果は、監視移設で凍結コピーを読ませない、初回状態引き継ぎの設計で確認できます。

8月1日公開：コピー結果は終了表示ではなく中身で判定する

共有フォルダへの同期では、ディレクトリだけが作られ、ファイル内容が欠落しました。一方、別のコピー手段は権限設定のエラーを返しつつ内容自体は書き込まれていました。ここでは1.3MB・16ファイルをバイト単位で照合し、全件一致を完了条件に置いています。

同期と退避の確認観点は、共有フォルダ同期で空ディレクトリだけ作られた移設記録に残しています。

8月2日公開：監視はDOWN表示だけでは運用にならない

この公開記録が扱う事象は7月25日です。GPUドライバ更新後、GPU状態を読む処理と生存報告が約11時間48分止まりました。監視サービスはDOWNを記録していましたが、この項目には通知先が結び付いていませんでした。復旧では、共有機を自動で停止させず、再起動の相談と実行を分離する形を採りました。

版ズレ、通知経路、再起動承認の経緯は、GPUドライバ更新後に監視が止まった11時間48分と再起動承認で詳しく読めます。

実測から見えた共通点

二重ポーリングは60秒ごと、systemdの問題では39バイトの警告だけ、凍結コピーの移設対象は9本・約1300行、共有フォルダの照合対象は16ファイル、GPU監視停止は約11時間48分でした。規模も症状も異なりますが、どれも「存在する」「更新された」「成功と表示された」のいずれかを完了条件にしていたなら見逃し得る型です。移設の最後には、対象ごとに旧側の停止、初回実行の内容、状態と出力の保存先、成果物の一致、通知先を並べて確認するのが次の一手になります。

よくある質問

移設直後に最初に確認するなら何ですか？

外部へ作用する処理は、まず新側の起動と旧側の停止を分けて確認します。その後、初回実行のログ内容や成果物を見ます。

ログの更新時刻が新しければ成功ですか？

いいえ。今回の記録では、警告1行で本体が起動しないままログだけが更新された例がありました。処理の開始・完了、または期待する成果物を確認します。

監視サービスがDOWNを記録していれば十分ですか？

十分ではありません。誰に、どの経路で通知されるかまで設定されて初めて、停止を運用上発見できます。