よくある障害：昨夜は Telegram が返ったのに朝は無言
セッション依存です。対話シェル上のゲートウェイは ssh 切断や端末終了で落ちます。当番が「サービス障害」と呼ぶ事象の多くは、アプリの不具合ではなくプロセスツリーの帰属が原因です。
アップグレードのドリフトです。npm i -g やチャネル切替後に openclaw のパスが変わるのに、plist が古いバイナリを指したままだと、起動が不安定に見えます。
コンテナとの混同です。Docker は独自の再起動ポリシーを持ちます。ベアメタルの リモートMac や VPS では launchd／systemd を明示し、本番の型 と揃えます。
前景だけでは足りない理由
本番には予測可能な再起動、標準出力の永続化、リソース上限が要ります。前景だけではクラッシュ後のバックオフやログ連携が弱く、メンテ窓の順序ある reload も難しいです。先に 段階的排障 を読み、「繋がる」を「ユニットが健康」と言い換えます。Nginx／Caddy の上流が不安定だと 502 が増え、TLS のせいに見えがちです。
アップグレード記録には Node のマイナー、OPENCLAW_ 系の環境変数、プラグインディレクトリを残し、reload 前に openclaw doctor のスナップショットを取ります。
macOS：launchd の最小 plist と PATH
launchd では ProgramArguments に絶対パスを書き、EnvironmentVariables で PATH と必要なら NODE_BINARY を注入します。StandardOutPath／StandardErrorPath はローテーション可能な場所へ。KeepAlive と ThrottleInterval で再起動嵐を抑えます。ユーザー域は ~/Library/LaunchAgents、launchctl bootstrap で読み込み、変更後は kickstart -k です。詳細は 導入パス と照合してください。
ノートのスリープ設定はバックグラウンドジョブに影響します。常時稼働の Mac mini でも、ログアウト後にユーザエージェントが止まるポリシーに注意します。
Linux：systemd と Restart、LimitNOFILE
[Service] で User、WorkingDirectory、ExecStart を明示し、openclaw gateway またはラッパへ向けます。Restart=always と RestartSec= でバックオフし、LimitNOFILE は接続負荷に合わせます。unit を変えたら systemctl daemon-reload が必須です。Docker 本番 と比較し、裸 systemd はホスト I/O に近く、コンテナはピン留めに強い、と捉えます。
判断表：launchd、systemd、Docker の選び方
| 環境 | 第一候補 | 得られること | 典型の坑 |
|---|---|---|---|
| 長期稼働のリモートMac | launchd＋ログローテ | ログインセッション非依存 | PATH／Node のズレ |
| Linux VPS | systemd | journal とリソース制御 | ユーザー unit と root の混線 |
| 多インスタンス | コンテナ＋ compose | イメージの固定 | ボリュームとホスト設定の不一致 |
| 開発のみ | 前景＋ tmux | 速い反復 | クラッシュ復旧なし |
使い方は、成功の観測信号（systemctl is-active、ポート、doctor に新規 CRITICAL が無いこと）を先に定義してから行を選びます。
実装骨格（教材用）
# macOS: ~/Library/LaunchAgents/com.example.openclaw.gateway.plist
# ProgramArguments: /abs/openclaw gateway
# KeepAlive / ThrottleInterval を検討
# launchctl bootstrap gui/$(id -u) ...
# Linux: /etc/systemd/system/openclaw-gateway.service
# Restart=always / RestartSec=5
# systemctl daemon-reload && systemctl enable --now openclaw-gateway
本番ではユーザー、環境ファイル、権限、変更管理を足し、アップグレード後はパス検証を繰り返します。
ヘルスチェックとログの基線
運用手順に、openclaw status の非ゼロ、gateway サブコマンド異常、doctor の CRITICAL 増加、単一ログの肥大化のうち二つ以上を組み合わせたアラートを書きます。バックオフは指数または固定間隔にし、チャネル再接続 の嵐と重ねないようにします。
同じ数値を SFTPMAC の リモートMac ホスティングの受け入れ基準にも流用でき、「なんとなく通る」から脱却します。
FAQ とホスティングの位置づけ
cron で毎分起こしてよいですか
主手段には向きません。systemd／launchd の再起動意味と重複し、順序あるアップグレードが壊れやすいです。
Docker と systemd の両方で同じ GW を管理してよいですか
二重管理は避け、境界を runbook に一本化します。
doctor は緑なのにチャネルだけ落ちます
上流プロキシや DNS を疑い、ゲートウェイ再起動だけに頼りません。
まとめです。デーモン化はセッションとクラッシュ回復の問題を解き、判断表は launchd、systemd、コンテナの選択を助けます。
限界です。自前ノードは OS パッチ、ログ、鍵ローテを抱えます。SFTPMAC は七二四運用と手順を束ね、試行錯誤の負担を下げます。
ホスト型リモートMacでゲートウェイ入口と運用手順を揃えます。