Болевые точки когда демон врёт
Боль 1: PID достаточен. Неверно: циклы рестарта. См. эксплуатацию и doctor.
Боль 2: забыли linger. user systemd умирает с SSH сессией.
Боль 3: путают force и uninstall. Разная семантика.
Боль 4: нет логов launchd. Матрица.
Боль 5: игнор прокси. TLS прокси.
Боль 6: связка типовых ошибок. Снимки без SHA256 unit, linger на людских аккаунтах, RPC только с loopback. Связывайте gateway install --force с тикетом semver и материалами 4.x, WSL2 и отката. Фиксируйте semver, хеш doctor, linger, p95 RPC, notAfter сертификата, счётчик рестартов супервизора и свободное место под логи.
Официальная лестница и RPC против живого PID
openclaw status, статус шлюза, логи, openclaw doctor без fix. doctor --fix только после снимка по откату. RPC по публичному DNS как у клиентов.
Для каждого инцидента фиксируйте UTC-время, хеш сборки, флаг linger, последовательность команд и соответствие между кодами на TLS-краю и строками в логах шлюза. Так смена дежурных не порождает три взаимоисключающие версии. Комплаенс предпочитает воспроизводимую цепочку доказательств, а не одиночный скриншот. В проде планируйте синтетические RPC-пробы и храните метрики столько же, сколько access-log обратного прокси, чтобы связывать дрейф задержек с выкладками. Привязывайте шаги лестницы к внутренним статьям или тикетам, чтобы новичок мог повторить сценарий без импровизации.
Для высоконагруженных шлюзов полезно заранее зафиксировать, какие метрики считаются обязательными в каждом тикете: semver CLI и шлюза, хеш вывода doctor без фикса, SHA256 plist или unit, флаг linger, p95 синтетического RPC, notAfter сертификата, свободное место на разделе журналов и счётчик рестартов супервизора. Без этого набора постмортем превращается в обсуждение ощущений. Если на одной машине соседствуют npm global и Docker, явно укажите авторитетный путь в тикете, иначе разные дежурные будут чинить разные деревья файлов.
После gateway install --force сравните текст unit или plist с архивом построчно: тихий дрейф ExecStart или ProgramArguments часто проходит незамеченным, пока не сломается TLS или маршрутизация канала. Для журналов, отправляемых в SIEM, заранее согласуйте срок хранения и псевдонимизацию полей, чтобы не нарушать политику данных при расследовании. Разделяйте человеческие админские учётные записи и сервисные с linger, иначе персистентный user manager расширит поверхность атаки за пределы шлюза.
На macOS и Linux одинаково важно документировать взаимодействие с обратным прокси: двойной снимок заголовков Upgrade может убить WebSocket на краю, хотя локальный health остаётся зелёным. Сначала коррелируйте идентификаторы запросов в логах шлюза и прокси, и только затем включайте tcpdump по согласованию с безопасностью. Планируйте квартальный холодный ребут с заранее записанным сценарием, чтобы обновления ядра не стали первым стресс‑тестом для fstab и сетевых домашних каталогов.
Если на хосте крутятся CI‑агенты и сам шлюз, задайте cgroup или лимиты CPU, чтобы ночная сборка не вытеснила проверки RPC в окне короткой профилактики. Храните рядом с конфигурацией список внешних каталогов skills и плагинов с контрольными суммами: force не восстановит отсутствующие файлы вендора, и doctor может лишь указать на дыру.
Метал и пропускная способность диска редко бывают первым узким местом у шлюза чаще страдают очереди соединений и задержки DNS при всплесках переподключений. Зафиксируйте базовые значения file descriptor лимитов и сравнивайте их после каждого force, потому что drop‑in могут незаметно ужесточить лимиты. Для смешанных окружений с контейнерами документируйте, какие порты публикует хост, а какие проброшены внутрь, чтобы не лечить «недоступный шлюз», когда занят другой процесс с тем же номером.
Наконец, опишите пороги эскалации: когда достаточно точечного repair, когда требуется полная переустановка одного канала, а когда нужна изоляция хоста до форензики. Без явных порогов команды снова и снова выбирают самый дорогой путь «снести всё», хотя цепочка логов и хешей уже указывала на локальную порчу артефакта.
Короткая памятка для дежурного: сначала зафиксируйте время и версии, затем сохраните вывод doctor и хвост журнала, добавьте SHA256 unit или plist и результат короткой RPC‑пробы, и только после этого обсуждайте force или деинсталляцию с владельцем сервиса.
macOS launchd
После gateway install --force сверяйте plist ProgramArguments и пути логов.
На macOS различайте пользовательский и системный домен bootstrap: ошибочный домен даёт «зелёный» процесс в одной сессии и отсутствие сервиса после перезагрузки. Храните рядом с снимком вывод launchctl print и список загруженных джобов, чтобы откат не превратился в угадывание. При публикации нового minor OpenClaw перечитывайте заметки о путях к Node и пересобирайте plist даже если JSON не менялся. Документируйте права на каталоги логов и агентов наблюдаемости, иначе команда увидит пустые файлы и решит, что шлюз «молчит» из-за логики приложения, хотя причина в правах или ротации.
KeepAlive с чрезмерным ThrottleInterval может скрывать быстрые падения: добавьте алерты по stderr и по кодам выхода, чтобы отличать шум от реальной деградации. Фиксируйте абсолютные пути в ProgramArguments и проверяйте which openclaw после каждого обновления менеджера пакетов. Если несколько LaunchAgents имеют похожие Label, введите однозначный префикс окружения, чтобы не получить двойной слушатель на одном порту.
Для цепочек TLS на самой машине храните notAfter и отпечаток рядом со снимком plist: ротация сертификатов часто независима от релизов OpenClaw. После force немедленно сделайте diff plist к архиву, чтобы подтвердить, что изменились только ожидаемые строки.
systemd user и loginctl linger
loginctl enable-linger, проверка Linger=yes, перезагрузка без консоли. Для Windows рядом читайте WSL2.
После включения linger проверьте, что юнит действительно WantedBy=default.target в пользовательском менеджере, а не случайно остался привязан к графической сессии. Снимите метрику до и после systemctl --user daemon-reload, чтобы исключить гонку между правкой unit и перезапуском. Для серверов с сетевыми домашними каталогами добавьте в чек-лист проверку автомонтирования до старта шлюза.
Фрагменты drop‑in в ~/.config/systemd/user версионируйте так же, как код: автор, дата, ссылка на тикет. Если контейнерные и bare metal unit делят имя, возможны гонки при reload документируйте уникальные префиксы окружений. Для экспорта journald в корпоративные хранилища включите шифрование транспорта и согласуйте сроки хранения с политикой данных.
Настройте таймер или cron, который после включения linger проверяет RPC, свободное место и наличие ожидаемых бинарников, чтобы переключатель не был разовым актом, а измеримой устойчивостью на горизонте релизов.
Измеримые базовые показатели для каждого хоста шлюза (2026)
Зафиксируйте адрес прослушивания из openclaw gateway status; в документации часто встречается порт 18789 для локальной консоли—это лишь ориентир. Версию Node сравните с минимумом, который требует openclaw doctor, и укажите в тикете. На разделе с долгими журналами держите ≥15% свободного места. После loginctl enable-linger выполните холодную перезагрузку и RPC-проверку по тому же публичному DNS и сертификату, что используют клиенты. В снимок включайте SHA256 текста unit/plist и путь which openclaw.
Дополнительно сохраняйте счётчик рестартов супервизора и последнюю известную p95 задержку RPC, чтобы после force сравнение с базовой линией показало регрессию сети, а не «улучшение по ощущениям», и приложите метку времени снимка для внутреннего аудита.
| Поле | Пример | Зачем |
|---|---|---|
| Semver CLI / шлюза | 2026.4.x | Связь инцидента с бинарником |
| SHA256 plist или unit | 64 hex | Тихий дрейф ExecStart после force |
Linger | да / нет | Доказательство без SSH |
| p95 RPC | напр. <300 мс на LAN-краю | Сеть против приложения |
| Свободно под логи | ≥15% | Сохранение улик при ротации |
gateway install --force и шаги
# 1) openclaw status
# 2) openclaw gateway status
# 3) logs
# 4) openclaw doctor
# 5) gateway install --force
# 6) systemctl --user daemon-reload && systemctl --user restart SERVICE
# 7) loginctl enable-linger USER
- Снимок JSON секретов unit фрагментов прокси.
- Лестница без fix.
- force repair при локальной порче.
- Перезагрузка супервизора и холод MCP.
- linger и headless тест.
- Синтетические RPC и каналы.
- Uninstall при коллизии путей.
Матрица FAQ SFTPMAC
Таблица ниже задаёт общий язык между разработкой и эксплуатацией: она запрещает «переустановить всё» без цепочки доказательств и фиксирует, какие сигналы относятся к сети, а какие к шлюзу. Дополняйте строки регионом, представлением DNS и номером тикета, чтобы аудит не зависел от чатов. При необходимости добавьте версию обратного прокси как скрытое поле, чтобы быстрее находить регрессии WebSocket на краю, а не внутри процесса.
Для команд, которые одновременно ведут несколько веток клиентов, полезно хранить отдельную строку на каждую комбинацию канала установки и целевой среды. Тогда сравнение p95 и доли ошибок между средами перестаёт быть спором о субъективных ощущениях и опирается на те же поля, что уже собирает шлюз. Если внезапно выросла только доля таймаутов на одной среде, сначала ищите сетевые отличия и сертификаты, прежде чем снова запускать gateway install --force на всех хостах подряд.
| Сценарий | Действие | Доказательство | Риск |
|---|---|---|---|
| RPC ошибка процесс жив | Лестница рестарт | Логи SNI | Ложный loopback |
| Порча артефактов | force repair | doctor | Потеря хотфикса |
| SSH гасит сервис | linger | Linger=no | Неверный scope |
| npm и Docker | Один канал | which | Долгий простой |
Почему после SSH всё падает
Сначала проверьте loginctl show-user для сервисной учётной записи и убедитесь, что Linger=yes. Если linger включён, но сервис исчезает, исследуйте сетевые home, VPN и готовность XDG_RUNTIME_DIR к моменту старта user manager. SSH ControlMaster может оставлять сессию искусственно живой тестируйте сценарий без мультиплексирования и с холодным ребутом. Любой исправляющий шаг фиксируйте в виде изменения unit/plist с версией, а не только интерактивными командами.
force это uninstall
Нет. gateway install --force обновляет управляемые шлюзом артефакты и связанные точки интеграции в выбранном канале установки, тогда как деинсталляция снимает более широкие обёртки и сервисные поверхности. Путаница ведёт либо к остаточному мусору, либо к лишнему простою. Полная деинсталляция уместна при коллизии semver деревьев или сомнении в целостности, когда хеши и логи не дают уверенного ответа.
Живого процесса достаточно
Нет. Живой PID не гарантирует корректный RPC‑маршрут, валидные TLS имена для реальных клиентов и свежую регистрацию дочерних процессов MCP. Сочетайте структурированные логи, синтетические пробы через публичный DNS и сравнение p95 с историческими базовыми уровнями, чтобы отделить сеть и прокси от логики шлюза.
Итог: шлюз это системный стек, а не один бинарник: супервизор, linger, TLS и RPC должны сходиться в одной картине наблюдаемости. Практичный критерий готовности к продакшену — когда дежурный может за пятнадцать минут воспроизвести лестницу статус→шлюз→логи→doctor, приложить хеши unit и plist, показать флаг linger и вывести свежую синтетическую пробу RPC с тем же именем, что видит клиент. Если какой‑то из этих артефактов отсутствует, формальная «зелёность» процесса мало что доказывает аудиторам или партнёрам по интеграции.
Ограничения: self hosted дорог по вниманию: патчи ОС, ротация секретов, журналы и дисковые квоты остаются на вас. На разрозненных ноутбуках сложно гарантировать одинаковые версии launchd plist, одинаковые тайминги linger и одинаковые пути логов, поэтому инциденты плохо переносятся между людьми. SFTPMAC удалённый Mac с SFTP и rsync снижает разброс образов между разработчиками и ускоряет повторяемые выкладки, потому что окружение остаётся доступным круглосуточно и ближе к реальному продакшену Apple, чем смесь локальных виртуалок.
Мост: ценность runbook в том, что он снижает цену эскалации и ускоряет обучение; предел разрозненных ПК — в дрейфе конфигураций и нехватке общих снимков; выгода хостинга 7x7 — в стабильном железе, предсказуемых обновлениях и едином месте для артефактов, где force и linger проверяются теми же сценариями, что и у заказчиков.
Панель: версия снимок linger RPC.