Как почистить кэш 1С на Linux

Кэш 1С на Linux — это служебные файлы, которые платформа создаёт при подключении к информационным базам: скомпилированные метаданные, временные формы, настройки интерфейса. Со временем эти данные устаревают или повреждаются, и пользователь сталкивается с типичными симптомами: 1С показывает старую версию конфигурации после обновления, выдаёт ошибки формата потока, «зависает» на запуске или отображает формы с искажениями. Очистка кэша — стандартный первый шаг диагностики, который не затрагивает данные самой базы.

На Linux кэш расположен иначе, чем на Windows, и это часто сбивает администраторов, привыкших к папкам AppData. Здесь платформа хранит кэш в домашнем каталоге пользователя, а серверный кэш — в каталоге служебных данных агента сервера 1С. Ниже разобраны оба случая: очистка клиентского кэша на рабочей станции и очистка серверного кэша на сервере приложений.

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

Где 1С хранит кэш на Linux

Клиентская часть платформы (толстый и тонкий клиент, запущенные локально) создаёт кэш в домашнем каталоге пользователя. Стандартный путь выглядит так: ~/.1cv8/1C/1cv8/. Внутри находятся подкаталоги, названные по уникальному идентификатору (GUID) каждой информационной базы — именно в них лежит основной кэш метаданных. Рядом могут присутствовать служебные файлы: 1Cv8.pfl (параметры пользователя), def.1cc, файлы журналов и временные каталоги.

Сервер 1С:Предприятия хранит свой кэш отдельно — в рабочем каталоге агента сервера. По умолчанию это /opt/1cv8/x86_64/<версия>/ не содержит кэша; рабочие данные лежат в каталоге, заданном при установке, чаще всего /home/usr1cv8/.1cv8/1C/1cv8/ или путь, указанный параметром -d при запуске агента. Внутри находится каталог srvinfo с подпапками вида reg_1541 — там хранятся реестр кластера и серверный кэш сеансовых данных.

Как найти каталог кэша конкретной базы

Сложность в том, что папки кэша названы GUID-ами, и по имени непонятно, какая из них относится к нужной базе. Есть несколько способов сопоставить каталог с базой. Самый простой — посмотреть список баз в файле ~/.1cv8/1C/1cv8/conf/ibases.v8i: в нём перечислены базы из стартера с их идентификаторами. Откройте файл текстовым редактором и найдите строку ID=... в секции нужной базы.

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

Ещё один ориентир — время модификации каталогов. Команда ls -lt ~/.1cv8/1C/1cv8/ покажет папки, отсортированные по дате изменения: активно используемая база будет иметь самый свежий каталог. Это косвенный признак, но в сочетании с содержимым ibases.v8i он помогает точно идентифицировать нужную папку.

ls -lt ~/.1cv8/1C/1cv8/ | head -20

Очистка клиентского кэша вручную

Ручная очистка — самый контролируемый способ. Он подходит, когда нужно сбросить кэш одной конкретной базы, не трогая остальные. Перед началом полностью закройте все сеансы 1С на этой машине: и конфигуратор, и режим предприятия. Проверить отсутствие процессов можно командой ps aux | grep 1cv8 — если в выводе есть запущенные процессы платформы, завершите их штатно.

Далее перейдите в каталог кэша и удалите папку с GUID проблемной базы. Не удаляйте весь каталог ~/.1cv8 целиком: в подпапке conf хранятся настройки списка баз, а их потеря заставит заново добавлять базы в стартер. Удаляйте точечно — только каталоги GUID из ~/.1cv8/1C/1cv8/.

1. 1
   Закройте все сеансы 1С и проверьте отсутствие процессов: ps aux | grep 1cv8
2. 2
   Определите GUID базы в файле ~/.1cv8/1C/1cv8/conf/ibases.v8i
3. 3
   Удалите каталог кэша: rm -rf ~/.1cv8/1C/1cv8/<GUID_базы>
4. 4
   Запустите 1С и войдите в базу — кэш создастся заново
5. 5
   Проверьте, что исходная проблема устранена

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

Автоматизация очистки скриптом

На машинах разработчиков и тестовых стендах, где кэш приходится чистить регулярно, удобно использовать простой скрипт. Скрипт ниже удаляет все каталоги кэша баз, сохраняя настройки и список баз. Перед запуском убедитесь, что сеансы 1С закрыты, — скрипт этого не проверяет.

#!/bin/bash
CACHE_DIR="$HOME/.1cv8/1C/1cv8"
Удаляем только каталоги с GUID (длинные шестнадцатеричные имена)
find "$CACHE_DIR" -mindepth 1 -maxdepth 1 -type d \
-regextype posix-extended \
-regex '.*/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}' \
-exec rm -rf {} +
echo "Кэш баз очищен"

Регулярное выражение в скрипте отбирает только каталоги, чьи имена соответствуют формату GUID — это защищает от случайного удаления служебных подпапок. Сохраните скрипт, например, как clear_1c_cache.sh, сделайте исполняемым командой chmod +x clear_1c_cache.sh и запускайте по необходимости. Для регламентной очистки можно добавить его в cron, но делать это стоит только на машинах, где гарантированно отсутствуют ночные сеансы 1С.

Очистка серверного кэша 1С

Серверный кэш чистится иначе и требует большей осторожности, потому что затрагивает всех пользователей кластера. Он находится в рабочем каталоге агента сервера, внутри srvinfo: папки вида reg_1541 содержат реестр кластера и файлы кэша сеансовых данных с расширениями .dat и .bin. Удалять нужно только файлы кэша, ни в коем случае не сам реестр кластера (1CV8Clst.lst и связанные файлы) — его потеря означает потерю списка баз, зарегистрированных в кластере.

Правильная последовательность такова: завершите сеансы пользователей через консоль кластера или дождитесь окна обслуживания, остановите службу агента сервера (systemctl stop srv1cv8 — имя юнита может отличаться в зависимости от способа установки), удалите файлы кэша в каталоге srvinfo/reg_1541, оставив файлы реестра, затем запустите службу обратно. После старта агент создаст кэш заново.

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

Когда очистка кэша не поможет

Очистка кэша решает проблемы несоответствия локальных копий метаданных актуальной конфигурации, но не является универсальным средством. Если после полной очистки клиентского и серверного кэша ошибка воспроизводится, причина лежит глубже: повреждение данных в самой базе, ошибки в коде обновлённой конфигурации, проблемы с СУБД или сетью. В этом случае следующие шаги — проверка базы через конфигуратор («Тестирование и исправление» для файловой базы), анализ технологического журнала и журнала регистрации.

Отдельный случай — ошибка «Неверный формат хранилища данных», которая часто имитирует проблему кэша, но на самом деле указывает на повреждённый файл базы или кэша СУБД. Здесь очистка кэша 1С бессильна, требуется восстановление из резервной копии или штатные средства исправления. Поэтому перед любыми действиями с серверным кэшем и тестированием базы убедитесь, что актуальная резервная копия существует.

Профилактика и настройки, снижающие проблемы с кэшем

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

Также следите за свободным местом на разделе с домашними каталогами: при переполнении диска файлы кэша записываются не полностью и повреждаются, что порождает массовые ошибки у пользователей. Команда df -h ~ позволяет быстро проверить заполнение раздела. Держите в резерве свободное место с запасом — это дешёвая страховка от целого класса проблем.

Частые вопросы