linger · XDG_RUNTIME_DIR · デーモン検証 · 層別切り分け · APIリージョンと出口確認
プラットフォームエンジニア、SRE、自ホストAgent運用者が2026年にLinux VPSでOpenClawを載せるとき、典型失敗は「一度は手動で起動できた」ことではなく、SSH終了後にユーザーレベルのsystemdが止まること、非対話パスでXDG_RUNTIME_DIRが欠けること、Gateway・Channel・Modelのログを一塊りに読むこと、そしてコンソールで選んだAPIリージョンと実際の出口経路が食い違うことです。本稿では本番前五つの隠れコスト、ベアメタルsystemd・コンテナ内systemd・Dockerのみの三対照表、六段階の再現Runbookとコマンド例、チェックリストと引用可能な技術事実三つ、意思決定マトリクスを提示します。インストールとGatewayはインストールとdoctorチェックリスト、Compose常駐はDocker Compose生産基線と併読してください。注文は注文ページを参照します。
Linux VPSでのOpenClawは、長寿命プロセス、ソケットディレクトリ、ログ、再起動の意味論を個人の習慣から監査可能なユニットへ移します。以下の五つはセットで現れ、結論は一つです。Dockerの是非より先にlingerとXDG_RUNTIME_DIRを受け入れ基準に書く。
セッション結合：linger無しでは対話SSH終了後にユーザーのsystemd管理が止まり、夜間にユニットが静かに終了します。ログには「昨日は動いた」だけが残りがちです。
ランタイムディレクトリ欠落：cronや最小シェル、誤ったサービスタイプではXDG_RUNTIME_DIRが空になり、ソケット作成失敗がアプリとsystemdに分散します。
層別切り分けの省略：Gateway未待受、Channel資格情報、モデルルーティング、上流429を「OpenClawが壊れた」一語にまとめ、層ごとのサンプルを取りません。
リージョンと出口のズレ：コンソールや環境変数はリージョンAなのに、VPS経路の応答ヘッダはリージョンBの示唆を返し、安定403ではなく断続的な認証失敗に見えます。
境界の混在：同一ホストにDockerとユーザーユニットがあり、再起動順とヘルス意味論が食い違い、ロールバック時にどの層を止めるか不明確になります。
ホストユーザーユニットとコンテナPID1を比較する場合、次表はスローガンではなくレビュー投影用です。
再起動意味論、ログローテ、linger意味論、ソケットとホストポートの境界を誰が持つかから決めます。万能解はなく、スキルに合う運用境界だけがあります。
| モデル | 典型用途 | 主な利点 | 主なコスト |
|---|---|---|---|
| ベアメタルsystemd（ユーザー） | 単一VPSでホストfwとループバックに密接 | ディストロツールと整合、journalとユニットが一直線 | lingerとログインセッション境界の扱いが必須 |
| systemd-in-container | イメージ内の多プロセス監督 | 従来型Linuxサービスホストに近い | 特権とイメージ境界が鋭く、調査は内外両方 |
| Dockerのみ | Composeやオーケストレータがヘルスと再起動を保有 | 成果物の版管理とロールバックが明快 | ホストユーザーのlinger意味論は自動では引き継がれない |
再現可能な受け入れは「手元で動いた」ではなく、SSH終了後もユニットが残り、journalの理由が読め、同一コマンドでリージョン示唆を二度取れることです。
順序は、無人でもユーザーマネージャを生存させ、ランタイムDIRを確認し、ユニットを入れ、層別に切り分け、最後に出口スナップショットを取ります。各段階でコマンド出力を保存します。Gateway基線はインストールとdoctorチェックリストに戻ってください。
サービスユーザ固定：実行アカウントと主グループを固定し、rootと混在させない。成果物：idと短いloginctl user-status断片。
linger有効化：デプロイユーザにlingerを付与し、ログイン無しでもuser@を稼働。成果物：show-userでlinger=yes。
XDG_RUNTIME_DIR検証：ユニットと同じプロファイルから変数を表示し、/run/user/<uid>形を期待します。
導入と有効化：ユーザースコープにユニットを置き、daemon-reloadとenable --now、statusでActiveと主pidを確認します。
層別サンプル：先にGateway待受と設定解析、次にChannel資格情報とwebhook到達、最後にモデル上流の枠とリージョンヘッダ。各層でjournal末尾200行を残します。
出口整合：同一ホスト名で解決とTLS可視情報を変更前後に保存し、単一RTTを性能結論にしません。
loginctl show-user "${USER}" -p Linger
sudo loginctl enable-linger "${USER}"
systemctl --user show-environment | grep XDG_RUNTIME_DIR || true
echo "${XDG_RUNTIME_DIR}"
systemctl --user daemon-reload
systemctl --user status openclaw-gateway.service --no-pager
journalctl --user -u openclaw-gateway.service -n 200 --no-pager
注：openclaw-gateway.serviceは実ユニット名に置換してください。別ゲートウェイ名でもExecStartを正とします。
各項目に担当と再確認周期を割り当てます。リージョン確認は捏造ベンチではなく、再現可能なTLSと応答メタデータのみを集めます。
lingerゲート：変更票にshow-user Linger=yesのテキストまたは画像を添付します。
ユニット境界：ユーザーユニットがbindするポートとコンテナ公開ポートを明記し、fw文書を同期します。
ログ保持：journal永続化または転送方針を文書化し、デバッグログのディスク枯渇を防ぎます。
層別Runbook：Gateway・Channel・Model各層で「通過したら次へ」チェックを最低三つ保持します。
リージョンスナップショット：リリース窓の前後で解決結果とヘッダサンプルを保存し、ロールバック比較に使います。
loginctl enable-lingerはユーザーのsystemd管理器の生存境界に作用し、Docker選択と自動同値ではありません。/run/user/<uid>です。非ログインで欠落するとソケットは非writableへ退行します。注意：一度成功したcurlはCDN切替後の証明になりません。固定ホスト名と再現コマンドが単発成功より強いです。
linger、ユニット名、ポート表、リージョンスナップショットが版管理されていなければ、Linux常駐は半分です。残り半分はGateway切り分けと同じ責任言語です。表はレビュー投影用です。
| チーム状態 | 推奨既定 | 受け入れ信号 | 典型の罠 |
|---|---|---|---|
| 単独保守・高速試行 | Docker Compose基線 | ヘルスと再起動がcomposeでレビュー可能 | mem_limitとログローテ無視で擬似ハング |
| マルチテナント同一機 | コンテナ境界＋独立プロジェクト名 | スタックごとにデータディレクトリ分離 | ユーザーユニット混在で再起動競合 |
| ホスト密結合 | ユーザsystemd＋linger | SSH後もjournalが連続 | 非対話パスでXDG_RUNTIME_DIR未検証 |
対話bash、linger無しnohup、手書きウォッチドは変更レビューと監査で一括返済されがちです。上流リージョン方針変更時も出口スナップショット無しでは説明が難しくなります。一方、リージョン選択可能でネットワーク段階が読みやすい専用クラウドMac容量は、iOSビルドやデスクトップ引き継ぎと同じ監査フィールドで安定出口とゴールデンイメージを資産化しやすいです。
典型の罠：Dockerでsystemd意味論が全部消えると思うこと。Compose外でユーザーユニットがゲートウェイを抱えるならlingerとランタイムDIRは依然ハードゲートです。
個人スクリプトと版管理されない環境エクスポートは引き継ぎとコンプライアンスで外部SLAに耐えにくく、OpenClawを上流リージョン方針・TLSフィンガプリント・固定出口説明と一緒に出荷する場面では、bashのみの代替は監査可能な変更票を欠きがちです。iOS引き継ぎ、CI回帰、自動化Agentを一つの受け入れにまとめ、注文とリージョン段階で自建出口の博打を減らしたいチームにとって、VpsMeshのMac Miniクラウドレンタルは多くの場合より良い適合です。専用ノードはACLとホスト名固定を簡素化し、高頻度ループに近い協働を保ちつつ、チーム私網ビルドノードRunbookと同じ運用語彙に揃えられます。地域組合せは価格ページ、接続境界はヘルプセンターを正としてください。
対話セッション終了後にsystemd --userが止まり、ユーザーレベルのOpenClawユニットも終了することがあります。本番前にlingerを確認し、夜間停止を上流障害と誤認しないようヘルプセンターの接続と常駐ガイダンスと突き合わせてください。
ホスト名とツール版を固定し、解決結果と同一エンドポイントのTLS可視情報を保存します。コンソールのリージョン設定と環境変数を突き合わせます。Composeレベルのヘルス意味論はDocker Compose生産基線を参照してください。
再起動、ログローテ、上限、ヘルスチェックがComposeまたはオーケストレータに宣言され、ホストユーザーソケットとlinger意味論に依存しない場合、Dockerのみで十分なことが多いです。ユーザーユニットと混在する前に第三节の層別受け入れを完了してください。