Где находится кэш 1С в Linux и как его очистить

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

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

Зачем 1С создаёт кэш и что там хранится

Клиент 1С кэширует метаданные конфигурации, скомпилированные модули и элементы интерфейса, чтобы не запрашивать их у сервера при каждом запуске. Благодаря этому повторный вход в базу происходит заметно быстрее. Для каждой информационной базы создаётся отдельный каталог с именем в виде GUID — уникального идентификатора базы.

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

Сервер 1С (агент сервера) тоже ведёт собственный кэш: там хранятся сеансовые данные, временные таблицы и служебные файлы кластера. Его повреждение встречается реже, но тоже бывает причиной странного поведения баз.

Где кэш клиента 1С: каталог ~/.1cv8

У каждого пользователя Linux, запускающего 1С, кэш лежит в домашней папке. Основные пути:

• ~/.1cv8/1C/1cv8/ — кэш метаданных и настройки клиента. Внутри — подкаталоги вида reg_1541 (для соединений через сервер с портом 1541) и каталоги с GUID баз.
• ~/.1cv8/1C/1cv8/conf/ — пользовательские настройки интерфейса (файлы .cfl).
• ~/.1cv8/1C/1cv8/1cv8u.pfl — файл пользовательских настроек.

Каталог ~/.1cv8 — скрытый: в файловом менеджере он не виден, пока не включить отображение скрытых файлов (обычно Ctrl+H). В терминале достаточно выполнить:

ls -la ~/.1cv8/1C/1cv8/

Для файловых баз (когда база лежит прямо на диске, без сервера) кэш также создаётся в этом же дереве каталогов, а имя подкаталога формируется от пути к базе с заменой служебных символов.

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

Если баз несколько, определить нужный GUID-каталог можно двумя способами. Первый — по времени изменения: каталог проблемной базы будет изменяться при её запуске. Команда:

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

Второй способ — универсальный поиск по всей системе, если вы не уверены, под каким пользователем работал клиент:

find /home /root -type d -name '1cv8' 2>/dev/null

Ещё один надёжный приём — в клиенте 1С открыть список баз, выделить нужную и посмотреть параметры подключения. Для серверной базы кэш идёт в подкаталог reg_1541 (или с другим номером порта кластера), что сразу сужает поиск.

Как безопасно очистить кэш клиента

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

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

Если удалять весь каталог не хочется, безопасная альтернатива — переименовать его: mv ~/.1cv8 ~/.1cv8.bak. После проверки, что всё работает, резервную копию можно удалить. Это удобно, когда не уверены, какие настройки понадобятся снова.

Учтите: удаление каталога conf сбрасывает расположение окон, размеры колонок и прочие персональные настройки интерфейса. Если задача — только починить ошибку метаданных, ограничьтесь удалением каталогов с GUID и reg_1541.

Где кэш сервера 1С и как его чистить

На сервере Linux агент 1С хранит служебные данные в каталоге srvinfo. Его расположение зависит от способа установки:

• /opt/1cv8/x86_64/8.3.XX.XXXX/ — рядом с установленной платформой;
• /var/1cv8/ или путь, заданный параметром -d при запуске агента (смотрите unit-файл systemd или скрипт запуска).

Найти актуальный путь помогает команда ps aux | grep ragent — в строке запуска виден параметр -d с каталогом кластера. Внутри srvinfo лежат подкаталоги reg_1541 (реестр кластера и сеансовые данные), журналы и временные файлы.

Очистка серверного кэша делается только при остановленном агенте:

sudo systemctl stop srv1cv8
sudo rm -rf /var/1cv8/reg_1541/snccntx*
sudo systemctl start srv1cv8

Файлы вида snccntx — это кэш сеансовых данных, их удаление безопасно. А вот файлы реестра кластера (1CV8Clst.lst и подобные) удалять нельзя — вместе с ними пропадёт список баз, зарегистрированных в кластере, и базы придётся добавлять заново.

Альтернативы ручному удалению

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

Ещё вариант — параметр запуска /ClearCache не существует как отдельная команда клиента, но в конфигураторе при отладке можно сбросить кэш отдельных объектов. Для массовой чистки на многих машинах удобнее написать скрипт, который завершает процессы 1С и удаляет содержимое ~/.1cv8/1C/1cv8/reg_1541/ у всех пользователей.

Как проверить, что очистка помогла

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

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