Место на диске, занятое временными файлами

Некоторые пользователи обнаружили много гигабайт файлов с именами вида responses-state.json.ocx.<pid>.<seq>.tmp в домашнем каталоге opencodex (по умолчанию ~/.opencodex); после каждой перезагрузки их становилось больше.

Что это за файлы

opencodex хранит кэш продолжений, чтобы цепочки previous_response_id сохранялись после перезапуска прокси. Снимок записывается атомарно: сначала содержимое попадает во временный файл, затем одним действием заменяет основной. Так сбой посреди записи не оставляет наполовину записанный снимок.

Обычно временный файл удаляется сразу после замены. Если процесс завершится между этими шагами, файл останется.

Каждый файл может занимать до 24 МБ, поскольку снимок каждый раз переписывается целиком, а не дополняется. Несколько сотен оставшихся файлов быстро заполняют диск.

Это кэш, а не долговременное состояние. При их удалении лишь текущим цепочкам диалога может понадобиться один раз повторно отправить контекст. Конфигурация, учётные данные и история в них не хранятся.

Почему они могли накапливаться

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

Прокси после сбоя и перезапуска убирал файлы слишком рано, чтобы увидеть оставленный предшественником временный файл: действует 15-минутный период ожидания, чтобы не затронуть файл, записываемый сейчас. Затем до конца работы он больше не проверял каталог. Каждый перезапуск добавлял ещё один файл.

Хуже того, очистка пропускала любой файл, если процесс с указанным в нём id ещё работал. После перезагрузки ОС часто повторно выдаёт те же id процессов, поэтому старый файл мог навсегда считаться принадлежащим работающему процессу. Этим объяснялся рост после перезагрузок.

Что opencodex делает теперь

Очистка повторяется по обычному фоновому таймеру прокси, а не выполняется один раз при запуске. Поэтому работающий прокси сам удаляет оставшиеся файлы. Для файлов старше текущей загрузки системы проверка id процесса также игнорируется: ни один работающий процесс не может владеть ими.

Правила безопасности не изменились: файл моложе 15 минут никогда не удаляется, и прокси никогда не удаляет файл, который записывает сам.

Как часто записывается снимок

Записи откладываются с интервалом, зависящим от размера последнего фактически записанного снимка. Пока файл невелик, следующая запись назначается примерно через две секунды после изменения. При приближении к пределу 24 МБ ожидание увеличивается максимум до тридцати секунд. Поэтому только что выросший кэш ещё один раз записывается после короткого ожидания; более длинный интервал действует начиная со следующей записи. Сброс пропускается лишь тогда, когда этот процесс уже записал те же байты в тот же файл, файл на диске всё ещё совпадает и — кроме Windows — его права по-прежнему разрешают доступ только владельцу. Новый процесс один раз перезаписывает даже идентичный снимок. Если содержимое или права файла изменились вне прокси, он переписывается через защищённый путь.

За один обычный фоновый цикл выполняется не более одной полной атомарной перезаписи. Если кэш продолжений изменится во время записи, opencodex назначит ещё одну запись с обычной задержкой, а не станет немедленно переписывать весь снимок. При штатной остановке сохраняются ограниченные повторы после завершения текущих запросов, чтобы итоговый снимок успел обновиться до выхода процесса.

Вместе эти меры удерживают частоту записей примерно постоянной по мере роста кэша вместо сериализации и замены всего файла каждые две секунды.

При штатной остановке сброс выполняется сразу, без ожидания таймера. Поэтому длинная задержка главным образом увеличивает окно, в котором принудительное завершение может потерять последние записи продолжения — это кэш, как сказано выше. Такой сброс всё равно является записью на диск и может завершиться ошибкой; при заполненном томе или томе только для чтения записи тоже потеряются.

Удаление уже накопившихся файлов

Если прокси работает, очистка происходит автоматически за одну-две минуты.

Если прокси не запускается — именно тогда файлы накапливаются быстрее всего, — проверьте их из командной строки:

ocx doctor

Раздел «Response-state temp files» показывает число файлов, которые можно удалить, и занимаемое ими место. Команда только сообщает сведения и ничего не меняет.

Чтобы действительно удалить их:

ocx doctor --reclaim-response-temps

Обе команды работают без запущенного прокси. Файлы, заблокированные другим процессом, указываются в отчёте, а не удаляются принудительно. Следующая очистка попробует снова: автоматически при работающем прокси или при следующем запуске команды.

Если очень большой остаток не помещается в один проход, команда сообщит, сколько файлов осталось, чтобы её можно было повторить.

Это относится именно к временным снимкам состояния ответов. Другие компоненты создают свои временные файлы с похожими именами; они не затрагиваются.