Коротко
- Пользователь desktop_doug замерил рост времени апгрейда Gateway с 2.5 минут (2026.9.3) до 43.7 минут (2026.10.2), простой — с 2.2 до 33.5 минут.
- Большая часть времени уходит в фазу активации, пока Gateway остановлен: 31 минута против 3.6 минуты в 2026.9.7.
- Автор причины не назвал.
Сверено с документацией OpenClaw 2026.10.3, 15 октября 2026.
Пользователь desktop_doug в r-openclaw выложил таблицу обновлений своего Gateway: с 2026.9.3 по 2026.10.2 время выросло с 2.5 до 43.7 минут. Простой Gateway за тот же период вырос с 2.2 до 33.5 минут. Часть обновлений между ними сорвалась: 2026.9.5 пять раз падал с global-install-failed, 2026.9.8 — с gateway stop refused (эту версию автор пропустил), 2026.9.6 он ставил вручную после блокировки схемы БД, а после 2026.10.1 Gateway остался остановленным, и поднимал его openclaw update repair.
Что увидел автор
Почти всё время уходит в фазу активации, когда Gateway уже остановлен. На 2026.9.9 и 2026.10.2 автор замерил около 31 минуты в этой фазе, на 2026.9.7 — 3.6 минуты. openclaw update repair отдельно отрабатывает за 1–2 минуты. Тот же шаг doctor внутри полного обновления идёт около 12 минут за проход, при низкой загрузке CPU, с предупреждениями slow SQLite transaction hold.
База состояния за этот период выросла примерно на 25% (с ~306 до ~385 MiB в снимке обновления), а время обновления — в 10 раз. Размер базы сам по себе картину не объясняет.
Изначально Gateway был установлен через CLI npm как LaunchAgent. Потом автор поставил приложение для macOS, и оно пометило Gateway как independently managed. Автоапдейты приложения шли мимо Gateway и давали расхождение версий. Недавно он перевёл всё на установку под управлением приложения, и обновление 10.2 наконец прошло из приложения. Хост: iMac 2013 года, Intel Core i7-4771 3.5 GHz, 16 GB RAM, SSD Samsung 870 EVO 1 TB, macOS 15.7.7, Gateway на Node 26.8.1, бандл приложения тащит Node 24.21.0. Сейчас 1 агент (раньше 4), 8 плагинов, база состояния ~22 MB, основная база агента ~340 MB.
Как это собрать на OpenClaw
Сначала проверьте, какой бинарник отвечает за обновление и кто управляет Gateway:
which openclaw
openclaw --version
openclaw gateway status --deep
openclaw config get meta.lastTouchedVersion
openclaw update status --jsonЕсли версия бинарника в PATH отстаёт от meta.lastTouchedVersion, документация требует вначале починить PATH, затем переустановить сервис:
openclaw gateway install --force
openclaw gateway restartЗаодно уберите устаревшие системные обёртки, которые всё ещё указывают на старый openclaw. Если обновление застряло и оставило Gateway остановленным, общий путь восстановления по документации такой:
openclaw status --all
openclaw update status --json
openclaw doctor --fix
openclaw gateway restartВ openclaw status есть строка Update restart с ожидающими и упавшими передачами и подсказкой следующей команды. doctor --fix отдельно чинит устаревшие тени OAuth по агентам: после новой аутентификации все агенты должны выбирать общий профиль и не падать в 401.
По словам автора, время фаз видно в openclaw update status, в строке Phases:. Если её нет, смотрите отчёт о последнем обновлении в openclaw update status --json. Сравните своё время в фазе активации с авторскими 31 минутами.
Когда это не подойдёт
Хост у автора специфический: iMac 2013 на Intel, история с двойным управлением через CLI и установку под управлением приложения, расхождение версий Node. В треде есть и похожие жалобы (у одного пользователя каждая попытка шла 30+ минут до сбоя), и обратные примеры: на VPS с 4 ядрами и 8 ГБ обновление 10.1 → 10.2 заняло несколько минут. Общего диагноза нет, поэтому переносить выводы на свою машину рано.
Полезно проверить и соседние сценарии. openclaw doctor --deep показывает активные TCP-клиенты на порту Gateway с PID, это помогает при несовпадении протокола после отката. В ~/.openclaw/logs/stability/ лежат пакеты стабильности с *-uncaught_exception.json, там видна причина тихих падений, особенно на Mac с режимом обслуживающего сна. У двойных LaunchAgent ai.openclaw.gateway и ai.openclaw.node свой цикл перезапуска с EADDRINUSE, его лечат через openclaw node uninstall и установку Gateway с --wrapper. Признаки другие: повторяющиеся передачи в gateway.log и смена PID каждые несколько секунд.