В macOS шлюз OpenClaw часто находится под надзором launchd. Операторы — и иногда сами агенты — пытаются «просто перезапустить шлюз» из той же сессии, от которой он зависит. Так можно выгрузить LaunchAgent, пока инициирующий RPC ещё не отсоединился — что совпадает с реальными историями о шлюзах, которые не возвращаются, пока кто-то не зайдёт отдельной оболочкой. В runbook — почему так происходит, таблица решений для безопасных и рискованных действий, шесть развёрнутых шагов на хосте в дополнение к JSON-LD HowTo из семи шагов, плюс ссылки на восстановление и конкуренцию задач.
Перед изменениями прочитайте восстановление gateway LaunchAgent и интерактивный чат против длительных workspace-задач, чтобы перезапуски не сталкивались с тяжёлыми джобами. Первая установка: установка и развёртывание. Вопросы аккаунта — помощь; разнести шлюз и CI по двум хостам NodeMac — цены. Токены и дрейф plist: конфигурационный дрейф.
Режим отказа: самообезглавливание под launchd
Шлюз одновременно сервер и зависимость выполняемой команды. Если агент отправляет openclaw gateway restart по тому же RPC-каналу, которым владеет процесс шлюза, launchd может выполнить bootout до чистой передачи. CLI-сессия завершается транспортной ошибкой, и не остаётся супервизора, гарантирующего здоровый bootstrap — особенно на headless-хостах без наблюдателя за дисплеем.
- Симптом A:
gateway statusперескакивает из running в missing в ту же секунду, когда агент вызвал restart. - Симптом B: в логах строки unload launchd сразу рядом с ошибками отключения RPC.
- Симптом C: внешние проверки (HTTP health или TCP connect) таймаутятся минутами, пока не стартовала пользовательская сессия — типично для только SSH.
Матрица: кто может перезапускать шлюз
| Актор | Типичный контекст | Вердикт | Более безопасная альтернатива |
|---|---|---|---|
| Человек через второй SSH | Screen или ssh user@host | Предпочтительно | Документированная последовательность bootout/bootstrap; сохранить логи |
| Агент автоматизации внутри OpenClaw | Вызов инструмента во время чата | Избегать restart | Создать тикет; внешний оркестратор после mutex |
| Запланированный LaunchAgent | Ночной ремонт дрейфа | Допустимо при изолированном plist | Сдвинуть от пиков чата; см. выравнивание запланированных задач |
| CI-джоб на том же Mac | Шаг пайплайна «bounce gateway» | Не рекомендуется | Отдельная админ-очередь с отдельными учётными данными |
Вторая матрица: чеклист перед перезапуском
| Проверка | Критерий успеха |
|---|---|
| Владение слушателем | Ровно один PID на настроенную семью портов шлюза; PID записать для заметок отката |
| Место на диске для логов | Не менее 8 ГБ свободно на томе состояния и логов, чтобы перезапуск не оборвался записью |
| Mutex с длительными джобами | Ни один workspace-джоб не держит уровень mutex обслуживания шлюза, который вы задали |
| Непрерывность auth-токена | Клиенты могут перезагрузить токен с диска без интерактивного GUI-запроса |
Операционные цифры для каждого инцидента
- Бюджет холодного старта: до 90 секунд после bootstrap перед объявлением сбоя — дольше при ожидании антивируса или Full Disk Access.
- Интервал RPC-проб: каждые 5 секунд первую минуту, затем экспоненциальный backoff.
- Параллельные админ-действия: не более одной операции, меняющей шлюз, на хост.
Совет для headless: при подозрении на GUI-разрешения временно подключитесь по VNC, пройдите диалог один раз, затем снова только SSH.
Шесть шагов на хосте (нарратив к HowTo из семи шагов)
- Перестаньте слать команды через больной шлюз. Второе SSH на тот же Mac mini M4; эта сессия не должна зависеть от RPC, который вы перезапускаете.
- Соберите доказательства: статус, свежие логи, путь plist — сверьте с дрейфом конфигурации.
- Проверьте слушатель через
lsof, чтобы на лабораторной машине с несколькими экспериментами не сделатьbootoutчужого PID. - Выгрузите с корректной семантикой launchd для вашей версии macOS, затем bootstrap с диска, чтобы применились EnvironmentVariables и WorkingDirectory.
- Проверяйте здоровье, пока RPC из внешней оболочки не станет успешным; только потом переподключайте клиентов чата.
- Оставьте однострочную заметку об инциденте с временем, причиной и влиянием на чат/CI — корреляция с лимитами 429 станет простой.
FAQ
Можно ли автоматизировать перезапуски через Ansible?
Да, если playbook всегда использует управляющее соединение, которое не идёт через процесс шлюза, который вы перезапускаете. Относитесь к шлюзу как к БД: перезапуск с плоскости оркестрации, а не с клиентского запроса.
Несколько шлюзов для dev и prod?
Разные plist, порты и каталоги состояния. Документируйте, какой label LaunchAgent к какой среде относится, чтобы bootout никогда не задел не тот label.
Когда полностью разделять хосты?
Когда SLO чата и вытеснение CI конфликтуют даже с уровнями mutex — добавьте второй выделенный Mac mini M4 от NodeMac вместо наслоения несовместимых жизненных циклов на один граф launchd.
Надёжная работа OpenClaw опирается на ту же аппаратную историю, что и сборки: выделенный Mac mini M4 даёт производительность Apple Silicon с нативным macOS, SSH для headless-обслуживания и VNC при GUI-запросах разрешений, плюс выбор региона среди Гонконга, Японии, Кореи, Сингапура и США, чтобы операторы были ближе к машинам, которые будят в три ночи. Аренда вместо покупки делает экономически разумым второй хост «только gateway», когда этот runbook доказывает, что нельзя делить граф launchd между экспериментальными агентами и продакшен-чатом. Сравните тарифы по регионам, прежде чем наращивать риск на одном plist.