Болевые точки: почему шлюз пропадает ночью
Привязка к сессии. Процессы, стартующие из ssh или Terminal, наследуют жизненный цикл этой сессии. Выход, закрытие окна или обрыв сети часто убивают всё дерево, и шлюз кажется случайно недоступным. Операции воспринимают это как дефект приложения, хотя причина в отсутствии демонизации.
Дрейф путей и версий. После глобального обновления npm, смены канала релизов или пересборки Docker команда which openclaw указывает не туда, куда всё ещё смотрит plist или unit. Симптом — редкие отказы запуска, заметные после перезагрузки, а не после мягкого reload.
Лимиты дескрипторов и ресурсов. Шлюз с множеством каналов и инструментов открывает много файлов и сокетов. Без поднятых лимитов в unit или согласованного ulimit процессы умирают тихо или с обобщёнными кодами выхода, которые трудно сопоставить.
Прокси без стабильного upstream. Даже идеально настроенный TLS-терминатор отдаёт 502, если OpenClaw дёргается. Разбор начинается со стабильного процесса шлюза, прежде чем сомневаться в заголовках из Nginx и Caddy.
Смесь контейнера и железа. Docker локально, systemd на сервере, интерактив на Mac без правил порождают двойные механизмы перезапуска или их отсутствие. Политика в гайде стабильного производства должна назначить авторитетный runtime.
Интерактив не равен продакшену: сессии, логи, окна
Продакшен требует детерминированных перезапусков, вывода в файлы или структурированные журналы и документированных шагов обновления. Интерактив даёт быстрый фидбек, но не гарантирует продолжение после патча ядра, отключения питания или нехватки памяти. Функциональные тесты в терминале не учитывают обработку сигналов и поведение при выходе из сессии.
Логи должны ротироваться и сопоставляться с выводом openclaw doctor. Иначе размываются постмортемы. Диагностика каналов остаётся опорой в эксплуатации шлюза; резидентность делает проверки повторяемыми, потому что процесс не исчезает.
Окна обслуживания требуют последовательности: снизить трафик или освободить upstream, корректно остановить шлюз, обновить бинарники или образы, проверить конфигурацию, перезагрузить демон, подтвердить healthchecks, затем инвалидировать кэши прокси или CDN. Дисциплина согласуется с install.sh, npm и Docker, где описаны пути и откаты.
Наблюдаемость разделяет алерты состояния процесса и бизнес-сигналы. Активный systemd при пустой очереди — иной инцидент, чем сознательная остановка во время релиза. Runbooks должны различать эти случаи.
Профили разработки и продакшена должны изолировать переменные и файлы конфигурации. Случайно оставленный debug-флаг на демоне съедает CPU и маскирует реальные проблемы производительности потоком логов.
Документируйте ожидаемое поведение при перезагрузке ОС: некоторые зависимости шлюза могут стартовать позже сетевого стека, и тогда полезны юниты с корректными After= и Wants=, чтобы не получить гонку на старте.
Если шлюз использует локальные очереди или временные файлы, убедитесь, что путь к ним существует до запуска и что права соответствуют сервисному пользователю, иначе демон будет циклически падать с неочевидной ошибкой создания файла.
Согласуйте политику ретенции логов с командой безопасности: слишком короткая очистка ломает расследования, слишком длинная раздувает стоимость хранения и повышает риски утечки.
Наконец, фиксируйте контактные лица для эскалации по инфраструктуре сети и DNS: проблемы шлюза часто ошибочно списывают на приложение, хотя корень в истёкшем сертификате или неверной записи SRV.
macOS: launchd с абсолютными путями и явным доменом
launchd ожидает явные ProgramArguments без интерпретации shell. Любая скрытая зависимость от PATH ломается после следующего патча. Задайте EnvironmentVariables с PATH, LANG и проектными префиксами; закрепите NODE_BINARY, если это требует установка.
KeepAlive может ждать успешного выхода или перезапускать всегда; комбинируйте с ThrottleInterval, чтобы сдерживать циклы падений. Пользовательские агенты часто живут в ~/Library/LaunchAgents; безголовые Mac могут требовать глобальных агентов с влиянием на сон и энергию.
Стандартный вывод и ошибки должны идти в ротируемые пути, а не в неограниченные файлы домашнего каталога без аналога logrotate. Где возможно, подключайте централизованные конвейеры логирования для удалённых Mac.
Изменение plist требует bootout и bootstrap или точечного kickstart -k в зависимости от версии macOS и домена. Фиксируйте команды в runbook, чтобы дежурство не импровизировало.
Взаимодействие с Gatekeeper и подписью выходит за рамки статьи, но «бинарник не найден» похож на блокировку подписи. Храните ожидаемые хеши и сравнивайте с инструкциями по установке.
Power Nap, сон и крышка ноутбука реальны для портативных машин. Для шлюзов 24/7 на настольных или стоечных Mac зафиксируйте энергопрофили, чтобы управление питанием не душило сетевой стек.
Мультипользовательские среды требуют раздельных LaunchAgents по контексту. Не смешивайте глобальные демоны с пользовательскими путями — иначе появятся трудновоспроизводимые ошибки прав на токены или связку ключей.
Резервное копирование и версионирование plist — часть инфраструктуры как код. Без контроля версий теряется след ожидаемой минорной версии Node в продакшене.
Linux: unit systemd, Restart и ресурсы
Unit-файл должен содержать User, Group, WorkingDirectory и ExecStart с абсолютным путём. Restart=always или on-failure определяет, допустимы ли короткие ручные остановки. Добавьте RestartSec, чтобы избежать thundering herd при сбоях API или базы.
LimitNOFILE, TasksMax и MemoryMax защищают от неявного потребления. Шлюз, исчерпавший дескрипторы, падает с размытым симптомом; калибруйте лимиты на реальную нагрузку каналов и инструментов.
EnvironmentFile отделяет секреты от unit и позволяет ротировать их без переписывания всего файла. Права 600 и владение сервисным пользователем. После правок всегда daemon-reload перед restart.
Journald даёт структурированные логи; фильтруемые поля помогают коррелировать с прокси и приложением. Для долгой ретенции пересылайте в Loki, Elasticsearch или управляемый сервис согласно требованиям из гайда стабильной работы.
Socket activation редко нужен постоянно подключённому шлюзу; любые отступления документируйте явно.
Пользовательские и системные units меняют пути и логику автозапуска. Без интерактивной сессии системные units часто надёжнее при чистых правах.
Следите за давлением cgroup и событиями OOM. Процесс, упирающийся в MemoryMax, требует архитектурной работы, а не только большего лимита.
Обновления ядра и библиотек требуют плановых перезагрузок. Согласуйте их с окнами и предупредите потребителей каналов о кратковременных разрывах.
Матрица: launchd, systemd или контейнер
| Среда | Основной выбор | Выигрыш | Типичные ловушки |
|---|---|---|---|
| Удалённый Mac 24/7 | launchd и ротация логов | Независимость от shell, ясный домен агента | Дрейф путей и энергопрофиля |
| Linux VPS | systemd | Единый журнал, лимиты cgroup | Смешение пользовательских и системных units |
| Изоляция нескольких экземпляров | Контейнеры с Compose | Воспроизводимые образы | Маппинг томов для секретов и конфигурации |
| Чистая отладка | Интерактив или tmux | Быстрые итерации | Нет восстановления после сбоя |
| Смешанная эксплуатация | Один уровень супервизии | Ясная ответственность | Двойные перезапуски или ни одного |
Матрица не заменяет нагрузочные тесты. Подмешивайте реальный трафик и инструменты до фиксации лимитов. При сомнениях возвращайтесь к эксплуатации шлюза и рекомендациям TLS-прокси.
Скелеты: фрагменты plist и unit
# macOS: ~/Library/LaunchAgents/com.example.openclaw.gateway.plist
# ProgramArguments: /абсолютный/путь/к/openclaw gateway
# KeepAlive: true или SuccessfulExit
# StandardOutPath / StandardErrorPath → доступные ротируемые каталоги
# launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.example.openclaw.gateway.plist
# Linux: /etc/systemd/system/openclaw-gateway.service
# ExecStart=/usr/bin/env openclaw gateway
# Restart=always
# RestartSec=5
# LimitNOFILE=65535
# systemctl daemon-reload && systemctl enable --now openclaw-gateway
Фрагменты намеренно минимальны. Дополните ужесточением и зависимостями по внутренней политике. После каждого обновления проверяйте пути, как в гайде по установке.
Проверки здоровья: status, gateway, doctor, логи
Начните с openclaw status, чтобы исключить ошибки CLI и контекста. Затем подкоманды gateway для конфигурации и слушателей. Только после этого углубляйтесь в логи. Порядок отражает эксплуатацию шлюза и мешает гоняться за прокси до базовой готовности.
Предупреждения openclaw doctor оформляйте как рабочие пакеты, а не косметику. Храните выводы версионированно рядом с тегами релиза, чтобы видеть дрейф между средами.
Порты и WebSocket должны совпадать с обратным прокси из TLS и WebSocket. Проверяйте обновления на стейдже с той же unit или plist.
Комбинируйте алерты: процесс активен, но doctor критичен, или процесс активен, но очередь забита. Одна метрика часто врёт.
Runbooks должны описывать эскалацию при одновременных алертах, например после совместного обновления ОС и пакетов.
Держите время синхронизированным; без надёжного NTP корреляция логов выглядит хаотично и усложняет совместные постмортемы.
Делайте резервную копию конфигурации перед каждым релизом, чтобы сократить время восстановления; сверяйтесь с откатами из гайда по установке.
Healthchecks должны уважать плановые остановки без лишнего шума; используйте флаги обслуживания или тихие окна в мониторинге.
Долгое хранение вывода doctor может затрагивать приватность; минимизируйте поля и чистите чувствительные блоки по политике.
Интеграционные тесты после reload должны включать WebSocket upgrade и TLS handshake, а не только HTTP 200.
Завершайте постмортемы конкретными действиями по параметрам unit, а не общими призывами быть внимательнее.
Перед пиками нагрузки выполняйте синтетические проверки каналов, контролируемые вызовы инструментов и убеждайтесь, что фоновые задачи не делят ресурсы со шлюзом. Фиксируйте ожидаемые задержки, чтобы поддержка не расставляла неверные приоритеты.
Дополнительно полезно сравнивать профили задержек до и после смены сетевого маршрута или обновления TLS-библиотеки: иногда регрессия прячется не в логике шлюза, а в стеке сокетов.
Если в организации несколько независимых команд используют один хост, заранее определите владельца plist или unit и процедуру согласования изменений, иначе ночные правки затрут друг друга.
Для регулируемых отраслей фиксируйте, какие поля логов попадают в долгосрочное хранилище, чтобы юридический отдел не получил неожиданный набор персональных данных из отладочного вывода.
Регулярные учения на отказ одного узла показывают, успевает ли мониторинг поднять алерт до того, как пользователи заполнят очередь обращений.
В смешанных командах macOS и Linux унифицируйте термины состояний процессов, чтобы инцидент-чаты не ломались о терминологию.
Долгие наблюдения показывают сезонность и конец квартала; включайте эти паттерны в планирование мощностей вместо чисто реактивного масштабирования.
Обучение должно опираться на реальные фрагменты journal или logrotate, чтобы сократить онбординг.
Короткие чек-листы на каждом узле снижают человеческие ошибки при смене дежурства.
Окна обновлений и сосуществование с Docker
Планируйте минорные обновления Node и релизы OpenClaw совместно, чтобы не разъезжались ABI между двумя окнами. Фиксируйте ожидаемые эффекты из release notes во внутренних чек-листах.
При параллельных контейнерах избегайте конфликтов портов и двойного супервизора. Либо контейнер авторитетен, либо host unit, без полумер.
Миграции данных между путями хоста и контейнера хрупки; держите пути в одном версионируемом манифесте.
Канареечные выкладки могут слушать отдельный порт до переключения трафика. Явно документируйте откат.
Сообщайте о ожидаемых простоях или замедлении очередей внутренним пользователям, чтобы саппорт не захлёбывался ложными тревогами.
Общая стратегия должна совпадать с гайдом стабильной работы, включая бэкапы и ротацию секретов.
После крупных обновлений ОС снова запускайте doctor и перепроверяйте лимиты; параметры ядра могут измениться и сдвинуть дефолты для существующих units.
Автоматизируйте проверку units в CI, чтобы не ловить ошибки шаблонов путей.
Фиксируйте зависимости от внешних сервисов, чтобы чужие работы не выглядели как ваши падения шлюза.
Снимайте базовые метрики производительности до и после обновлений для объективных решений о ресурсах.
Завершайте каждое окно кратким отчётом: достигнутые метрики, остаточные риски, следующие проверки.
FAQ
Достаточно ли cron для перезапуска?
Не как основная стратегия; systemd и launchd дают лучшую семантику.
Порт 18789 занят?
Сначала локально, затем конфликты прокси или второй шлюз; см. эксплуатацию шлюза.
Два супервизора одновременно?
Избегайте; выберите один уровень и опишите его.
Когда контейнер вместо systemd?
Если важнее воспроизводимость образов; детали в Docker.
Итог и эксплуатация удалённого Mac
Итог: резидентность решает проблемы сессий и сбоев, передавая жизненный цикл ОС. Матрица помогает выбрать launchd, systemd или контейнер без дублирования ответственности.
Ограничения: даже идеальные units не заменяют проверенные прокси и цепочки TLS; сочетайте с гайдом по прокси и стабильной работой.
SFTPMAC поддерживает команды хостингом удалённых Mac, где эти runbooks можно отрабатывать без лишнего трения с железом. Цель — меньше ночных перезапусков и больше воспроизводимых результатов.
Поддерживаемые удалённые Mac и ясные runbooks снижают операционные потери.