Перейти к содержимому

← Блог

Что вышло

Chimera 0.74.1: остановка сервисов действительно останавливает, а зависимости подтянуты

Исправляет состояние гонки, при котором останавливаемый сервис исчезал из учета до своего завершения, и обновляет две транзитивные зависимости с известными уязвимостями.

Наш собственный текст о нашем же выпуске. Читать описание выпуска на GitHub →

У команды chimera service stop была гонка, из-за которой она врала. Вы говорили фоновому сервису остановиться, он подтверждал запрос и тут же пропадал из списка сервисов, хотя все еще работал. Если вы следом выполняли chimera service stop --now, чтобы принудительно убить зависший процесс, CLI отвечал «не запущен» — хотя процесс был жив и потреблял ресурсы. Версия 0.74.1 убирает этот зазор.

Почему останавливаемый сервис становился невидимым

Фоновый сервис Chimera выполняет долгоживущий агентский цикл. Получив сигнал остановки, он должен завершить текущие шаги, сбросить состояние и закрыть соединения. Старый код удалял запись о сервисе из трекера в момент принятия запроса на остановку. Это было упрощение в учете: сервис считал себя «останавливающимся», но для всей остальной системы он уже не существовал.

Непосредственная проблема проявлялась с флагом --now. Принудительная остановка ищет в трекере совпадающий идентификатор сервиса. Если записи нет, команда сообщает, что останавливать нечего, и выходит. Реальный процесс продолжал работать, удерживая блокировки, сокеты или память GPU, пока не завершал очистку самостоятельно или не прибивался извне. Для инженера, отлаживающего зависшего агента, это означало, что инструмент говорит «все в порядке», хотя таблица процессов утверждает обратное.

Что меняет исправление в жизненном цикле сервиса

Теперь сервис остается видимым в трекере со статусом stopping с момента принятия запроса на остановку и до самого выхода. Трекер хранит запись, так что любой последующий вызов stop или status ее увидит. Сервис выполняет корректное завершение — заканчивает текущий шаг, сохраняет все необходимое, закрывает циклы — и только потом удаляет себя сам. Запись исчезает лишь после того, как процесс действительно завершился.

Флаг --now по-прежнему существует, но его поведение стало строже. Он посылает сигнал принудительного завершения, только убедившись, что отслеживаемый процесс соответствует идентификатору сервиса в записи. Если сервис уже успел чисто завершиться между последней проверкой и вызовом --now, команда сообщит об этом вместо того, чтобы посылать сигнал переиспользованному PID. Это предотвращает случайное убийство посторонних процессов, которым достался тот же идентификатор.

Для тех, кто запускает несколько сервисов Chimera на одной машине, это убирает целый класс гейзенбагов, когда скрипт перезапуска поднимал новый экземпляр, пока старый еще завершался, потому что скрипт не мог увидеть старый экземпляр, чтобы дождаться его.

Патчи зависимостей, входящие в этот релиз

Две транзитивные зависимости обновлены для закрытия рекомендаций по безопасности. Ни одна из них не вызывается кодом агента Chimera напрямую, но обе присутствуют в цепочке поставки типовых рабочих процессов.

GitPython обновлен до 3.2.1. Версии до 3.2.0 проверяли путь .git подмодуля только после клонирования в него, что позволяло специально подготовленному репозиторию осуществить обход пути во время операции клонирования. Это важно, если ваш агент клонирует репозитории в рамках цикла вызова инструментов — например, агент код-ревью, который забирает пул-реквесты. Уровень опасности в рекомендации — высокий.

OpenTelemetry обновлен до 1.45.1. Предыдущий потолок, 1.45.0, разбирал заголовок tracestate без ограничения на количество записей. Смежный сервис, отражающий неограниченный tracestate обратно к вашему инструментированному агенту, мог вызвать чрезмерное потребление памяти. Собственные интерфейсы трассировки Chimera не затронуты, но любой агент, экспортирующий спаны в коллектор OpenTelemetry по HTTP, подвержен уязвимости через SDK. Уровень опасности в рекомендации — средний.

Оба патча — это поднятие минимальных версий в дереве зависимостей. Никакие программные интерфейсы не меняются. Если вы фиксируете зависимости лок-файлом, повторный запуск резолвера после обновления Chimera подтянет новые версии.

Обновление

Установите релиз напрямую:

pip install chimera-agent==0.74.1

Если вы используете Chimera CLI для управления запущенными сервисами, перезапустите всех долгоживущих агентов, чтобы они подхватили исправленное отслеживание жизненного цикла. Полный список изменений — в релизных заметках Chimera Agent v0.74.1.

https://chimeraagent.space