OpenClawアップデート後に起動不安定になったときの確認記録：migration lockとOOMの切り分け

※ChatGPT Plusでの作業。Gemini 3.1 Flash liteのOpenClawも同様にアップデート後起動しなくなりましたが、そっちのAIは途中で諦めて初期化ルートへ行き、登録していたタスクは真っさらに。。。今回の教訓はアップデート後はマイグレーションが走っている可能性があるので、しばらく待つ！！ですかね。最終的には復旧したっぽいですが、一時は両人（AI）ともお亡くなりになったかと。。。私の環境の場合、別記事で書いているように、memory周りの設定をいじっているので、そこでバージョンアップ後の移行に時間がかかったのかも。。。

OpenClawアップデート後に起動不安定になったときの確認記録

OpenClawをアップデートしたあと、Gatewayがうまく起動せず、修復処理を実行した環境がありました。今回は、追える範囲でログと設定を確認し、「設定が失われたのか」「起動処理やメモリ不足で不安定
になったのか」を切り分けた記録です。

なお、この記事では個別サーバ固有の実パス、ホスト名、ユーザー名、Discordの実IDなどはダミー化しています。実環境では、自分の環境に合わせて読み替えてください。

今回確認した結論

先に結論を書くと、今回の範囲では「OpenClawの設定ファイルが失われた」形跡は見つかりませんでした。

アップデート前バックアップと現在の設定を比較したところ、実質的な差分は最終更新バージョンや最終更新日時のメタ情報だけでした。SecretRefの状態も、平文化・未解決・重複シャドウの問題は見つか
っていません。

一方で、起動不安定の原因としては、アップデート直後のstartup migrationの競合と、その後のメモリ不足によるOOM killが確認できました。つまり今回の見立ては、設定消失ではなく「migration lockと
メモリ圧迫によってGatewayの起動・応答が不安定になった」です。

発生していた症状

確認できた症状は、おおむね次の通りです。

アップデート後、Gatewayが連続して起動失敗した
途中で修復処理を実行した
一時的にDiscord経由の応答やツール実行が不安定になった
Gateway再起動後、セッション復旧処理が走った
現在はGateway自体は起動しているが、メモリには余裕が少ない

確認に使った主なコマンド

まずはsystemd user serviceとして動いているOpenClaw Gatewayの状態を確認しました。

systemctl --user status openclaw-gateway.service --no-pager

あわせて、OpenClawのバージョンも確認しました。

openclaw --version

Gatewayの起動失敗やOOM killの痕跡はjournalから追いました。

journalctl --user -u openclaw-gateway.service \
  --since 'YYYY-MM-DD HH:MM' \
  --until 'YYYY-MM-DD HH:MM' \
  --no-pager

設定ファイルについては、アップデート前に残っていたバックアップと現在の設定を比較しました。実際のパスは環境ごとに異なるため、ここではダミー化しています。

diff -u \
  <(jq 'del(.meta.lastTouchedVersion,.meta.lastTouchedAt)' /path/to/openclaw.json.pre-update) \
  <(jq 'del(.meta.lastTouchedVersion,.meta.lastTouchedAt)' /path/to/openclaw.json)

SecretRefについては、OpenClawのauditで確認しました。

openclaw secrets audit --check

cronジョブはSQLite上の状態を確認しました。テーブル名やカラムはバージョンで変わる可能性があるため、まずschemaを見てから集計しています。

sqlite3 /path/to/state/openclaw.sqlite ".schema cron_jobs"

sqlite3 /path/to/state/openclaw.sqlite "
select
  count(*) as total,
  sum(case when enabled then 1 else 0 end) as enabled,
  sum(case when enabled and coalesce(consecutive_errors,0)>0 then 1 else 0 end) as enabled_with_errors
from cron_jobs;
"

時系列で見えたこと

アップデート直後にstartup migrationの競合が発生

最初に目立っていたのは、startup migrationがすでに実行中である、という理由による起動失敗でした。

[openclaw] The CLI command failed.
[openclaw] Reason: OpenClaw startup migrations are already running for this state directory;
retry after the other gateway finishes or after YYYY-MM-DDTHH:MM:SSZ.
openclaw-gateway.service: Failed with result 'exit-code'.
openclaw-gateway.service: Scheduled restart job, restart counter is at 1.

この状態では、別プロセスまたは直前の起動処理がstate directoryに対してmigrationを実行しており、後続のGateway起動がロックにぶつかって失敗していたと考えられます。

systemdの自動再起動により何度か再試行されましたが、ロックが残っている間は同じ理由で失敗していました。

その後、OOM killerによる強制終了が複数回発生

migration lockの時間帯を抜けたあとも、Gatewayは安定しきっていませんでした。journalには、OOM killerによってOpenClaw Gatewayのプロセスがkillされた記録が複数回残っていました。

openclaw-gateway.service: A process of this unit has been killed by the OOM killer.
openclaw-gateway.service: Main process exited, code=killed, status=9/KILL
openclaw-gateway.service: Failed with result 'signal'.
openclaw-gateway.service: Scheduled restart job, restart counter is at 1.

OOM killは、OSがメモリ不足時にプロセスを強制終了する動きです。OpenClaw側の設定が壊れたというより、起動直後の処理やプラグイン、セッション復旧、モデル関連処理などが重なり、メモリに余裕がな
くなった可能性が高いです。

Gatewayは再起動後にHTTP server listeningまで到達

最終的にはGatewayが起動し、HTTP server listeningまで到達していました。

[gateway] http server listening
[heartbeat] started

その後、Gateway再起動によって中断されたmain sessionを復旧する処理も確認できました。

[main-session-restart-recovery] marked 1 startup-orphaned main session(s) for restart recovery
[main-session-restart-recovery] resumed interrupted main session: agent:main:...
[main-session-restart-recovery] main-session restart recovery complete: recovered=1 failed=0 skipped=0

このため、少なくともGatewayの基本起動とセッション復旧処理は動作していると判断できます。

設定が失われていないかの確認

設定ファイルの差分

アップデート前の設定バックアップと現在の設定を比較しました。比較時には、アップデート後に変わって当然のメタ情報を除外しました。

jq 'del(.meta.lastTouchedVersion,.meta.lastTouchedAt)' /path/to/openclaw.json.pre-update
jq 'del(.meta.lastTouchedVersion,.meta.lastTouchedAt)' /path/to/openclaw.json

この比較では、ユーザーが設定した内容に相当する差分は見つかりませんでした。差分があったのは、最終更新バージョンや最終更新日時のようなメタ情報のみです。

SecretRefの状態

SecretRefの監査結果では、平文化・未解決・シャドウ化の問題はありませんでした。

Secrets audit: findings. plaintext=0, unresolved=0, shadowed=0, legacy=1.

legacy=1は、静的なSecretRef移行の対象外にある古いOAuth資格情報の残存を示すもので、今回のアップデートで設定が消えたことを示すものではありませんでした。

cronジョブの状態

cronジョブはSQLite上に残っており、集計では合計38件、そのうち36件が有効でした。有効ジョブの中に連続エラーを持つものは確認されませんでした。

total=38
enabled=36
enabled_with_errors=0

このため、スケジュール設定が丸ごと消えた、という状態ではありません。

残っている注意点

メモリには余裕が少ない

復旧後も、Gatewayのメモリ使用量は大きく、空きメモリはかなり少ない状態でした。実際の数値は環境差がありますが、今回の環境ではGateway関連プロセスが大きくメモリを使い、swapも使用されていまし
た。

Memory: around 1.5-1.6G used by gateway unit
Swap: in use
Available memory: low

この状態では、アップデート直後のmigration、プラグイン初期化、セッション復旧、モデルプリウォームなどが重なると、再びOOM killされる可能性があります。

一部の外部連携は未解決表示になることがある

Discord guildの一部について、OpenClaw側の設定は残っているものの、Discord側の解決ができていないものがありました。ここでは実IDを伏せています。

guild:<dummy-guild-id> unresolved

これは「allowlist設定が消えた」というより、現在の接続状態やDiscord側での参照可否の問題として扱うのが自然です。

control UIの警告

control UIについて、insecure authを許可している旨の警告も残っていました。

gateway.controlUi.allowInsecureAuth=true

ローカルや閉じた環境で意図して使っているなら即障害ではありませんが、外部から到達可能な構成では見直したほうがよい項目です。

今回の回復で確認できたこと

今回の回復後、確認できたポイントは次の通りです。

OpenClaw Gatewayはsystemd user serviceとしてactive/runningになっている
Gatewayはloopback上のポートで待ち受けている
OpenClawのバージョンはアップデート後のものになっている
設定ファイルの実質差分は見つからない
SecretRefの平文化・未解決・シャドウ化は見つからない
cronジョブはSQLite上に残っている
Gateway再起動後、main session restart recoveryが成功している

再発防止として見るべきポイント

アップデート直後はmigration完了を待つ

startup migrationが走るアップデートでは、途中でGatewayを何度も起動し直すと、migration lockにぶつかって起動失敗が連続することがあります。

同じエラーが出ている場合は、まず別のGatewayプロセスが残っていないか、migrationがまだ走っていないかを確認します。

systemctl --user status openclaw-gateway.service --no-pager
ps aux | grep openclaw

メモリ不足を疑う

Gatewayがstatus=9/KILLで落ちている場合、アプリケーション例外ではなくOOM killerの可能性があります。journalで次のような行を探します。

journalctl --user -u openclaw-gateway.service --no-pager | grep -i oom

メモリに余裕がない場合は、swapの増量、不要な常駐プロセスの停止、OpenClaw側のプラグインやセッション数の見直しを検討します。

設定消失は差分で確認する

「設定が飛んだかもしれない」と感じたときは、感覚ではなくバックアップとの差分を見るのが一番確実です。OpenClawがアップデート前バックアップを残している場合は、メタ情報を除外して比較すると判
断しやすくなります。

diff -u \
  <(jq 'del(.meta.lastTouchedVersion,.meta.lastTouchedAt)' /path/to/openclaw.json.pre-update) \
  <(jq 'del(.meta.lastTouchedVersion,.meta.lastTouchedAt)' /path/to/openclaw.json)

まとめ

今回のトラブルは、OpenClawアップデート後にGatewayが不安定になった事例でした。ログ上は、まずstartup migrationの競合で起動失敗が連続し、その後メモリ不足によるOOM killが複数回発生していまし
た。

一方で、アップデート前後の設定差分、SecretRef、cronジョブを確認した限り、ユーザー設定が失われた形跡は見つかりませんでした。

そのため、今回の結論は「設定消失」ではなく、「アップデート直後のmigration lockとメモリ圧迫による起動・応答不安定」です。復旧後もメモリには余裕が少ないため、同じような症状が再発する場合は
、まずjournalのOOM記録とGateway unitのメモリ使用量を確認するのがよさそうです。