ルールに書いた安全弁が、実機に本当に入っているかを機械で点検する
今回やったこと
自動公開の設定は、憲章や設計書に書かれているだけでは効かない。ジョブを止めたつもりでも launchd に残っている、設定ファイルを書き換えたのに再ロードしていない、環境変数が無いためスクリプトの既定値に戻っている、といったズレが起きるからだ。
そこで、期待する値を scripts/config/safety_valves.json にまとめ、実機の状態と突き合わせる点検スクリプトを実装した。対象は「値」「ロード状態」「設定ファイルと実効値の一致」の3つである。記事では、この3つを分けて見る理由と、点検結果を沈黙させないための設計を整理する。
3種類のズレを別々に捕まえる
最初に見るのは実効値だ。launchctl print の environment ブロックを読み、ジョブが実際に使っている値を取得する。plist に環境変数が無い場合、プロセス側の既定値が採用されることがある。設定が無いこと自体を検査しなければ、「設定したつもり」と「実際の動作」の差は見逃される。
次にロード状態を確認する。ジョブが launchd に載っていなければ、設定が正しくても動かない。逆に、停止したはずのジョブが残っていれば、無人公開などの処理が続く可能性がある。値の比較だけでは、この状態を判定できない。
最後に plist と実行中の値を比較する。ファイルを修正しても unload/load を忘れれば、次の再起動まで古い値が動き続ける。現在動いている値と次回起動時の値を一緒に出すことで、時限爆弾になり得る差を記録できる。
期待値(JSON) ─┬─ 実効値 → 値のズレ
├─ ロード状態 → 動作の有無
└─ plistの値 → 再起動後のズレ
監視自身が嘘をつかないための扱い
このスクリプトでは、終了コードだけを判定材料にしない。SSH経由の実行では、リモート側の終了コードを正しく返さず、成功に見える場合があるためだ。launchctl print の出力先頭にドメインヘッダーがあるか、標準出力に期待する値が含まれるかを確認して判定する。監視のための監視が環境差で誤報を出せば、運用者は通知を信用しなくなる。
異常が無い日も、常に通知するのではなく、7日に1度だけ生存報告を送る。何も届かない状態を「異常なし」と解釈しないための仕組みである。ズレがあれば終了コード1、点検不能な項目があれば2、全一致なら0という区別も、後続の自動処理で扱いやすい。
実装ステータス
実装済み。期待値の正本は scripts/config/safety_valves.json、点検本体は scripts/safety_valve_audit.py に置いている。実機の設定を変更する処理ではなく、状態を読み取って差分を通知する処理として分離している。
更新履歴
- 2026-08-23: 初稿
訂正履歴
なし。