Чистим кэш 1С под Linux: клиент, сервер и автоматизация

Клиентский кэш 1С на Linux лежит в домашнем каталоге пользователя, в ~/.1cv8/1C/1cv8/. Закройте 1С, удалите оттуда подпапки с именами-GUID и перезапустите клиент — платформа пересоздаст всё сама. На сервере 1С кэш живёт в каталоге кластера (обычно /home/usr1cv8/.1cv8/1C/1cv8/), и чистить его нужно только при остановленной службе.

Это касается любой конфигурации: Бухгалтерия, ЗУП, ERP и самописные решения хранят служебные данные на диске одинаково. Разница только в объёме: у большой базы кэш разрастается быстрее. Ниже — что именно удалять, в каком порядке и как не сломать запуск.

Зачем чистить кэш 1С на Linux и когда это нужно

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

• 🐌 после обновления конфигурации клиент открывает формы по-старому или тормозит;
• 🧩 в интерфейсе остались удалённые команды, не появляются новые разделы;
• ⚠️ «Ошибка при вызове метода контекста», «Конфигурация базы данных не соответствует сохранённой конфигурации» после замены файла .cf;
• 💾 в домашнем каталоге десятки гигабайт служебных файлов, а места на диске не хватает;
• 🔁 клиент «не видит» изменения, сделанные в конфигураторе, хотя сервер их применил.

Чистить «на всякий случай» каждый день не нужно. Следующий вход в базу после чистки идёт дольше: платформа заново строит кэш. На сервере с сотней пользователей это заметно.

Где лежит кэш 1С: пути на клиенте и сервере

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

Имена подпапок с GUID — это идентификаторы баз. Чтобы понять, какая папка чья, откройте ibases.v8i: у каждой базы там есть строка ID=…. Совпадающий GUID — ваш кэш.

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

ls -la ~/.1cv8/1C/1cv8/
du -sh ~/.1cv8/1C/1cv8/* | sort -h

Вторая команда покажет, какие папки раздулись сильнее всего.

Как очистить кэш 1С на Linux пошагово: клиентская часть

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

Шаг 1. Закройте все сеансы 1С пользователя

Убедитесь, что процессов клиента не осталось:

pgrep -a 1cv8

Если команда что-то вывела — закройте окна или завершите процесс kill <PID>. Удаление кэша у работающего клиента приводит к ошибкам и потере открытых форм.

Шаг 2. Параметр запуска /ClearCache

Самый аккуратный способ — запустить клиент с ключом, который чистит кэш сам:

/opt/1cv8/x86_64/8.3.*/1cv8 ENTERPRISE /ClearCache

Путь к каталогу платформы у вас свой: версия в имени папки различается, посмотрите ls /opt/1cv8/x86_64/. Ключ можно добавить в строку запуска ярлыка, но постоянно держать его там не надо — вы потеряете выигрыш от кэша.

Шаг 3. Ручное удаление папок базы

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

cd ~/.1cv8/1C/1cv8/
rm -rf ./<GUID-вашей-базы>

Подставьте реальный GUID из ibases.v8i. Для всех баз сразу удалите все каталоги-GUID, но файлы .pf и ibases.v8i оставьте:

find ~/.1cv8/1C/1cv8/ -mindepth 1 -maxdepth 1 -type d -regextype posix-extended \
  -regex '.*/[0-9a-f]{8}-([0-9a-f]{4}-){3}[0-9a-f]{12}' -exec rm -rf {} +

Запустите эту команду сначала без -exec …, чтобы увидеть список. Только потом добавляйте удаление.

Шаг 4. Временные файлы

Платформа складывает временные файлы с префиксом v8_ в каталог временных файлов, обычно /tmp. Старые, оставшиеся после падения клиента, безопасно удалять:

find /tmp -maxdepth 1 -name 'v8_*' -mtime +1 -delete

Параметр -mtime +1 оставляет файлы моложе суток: они могут принадлежать работающему сеансу.

Шаг 5. Кэш отчётов и локальные настройки

Результаты построения отчётов хранятся не отдельным файлом на диске, а внутри пользовательских настроек базы. Поэтому «кэш отчётов» на клиенте — это те же папки с GUID и временные файлы. Если отчёт показывает старые данные, дело обычно не в файловом кэше. Проверьте, не включена ли в настройках отчёта расшифровка по сохранённому варианту, и сформируйте отчёт заново кнопкой «Сформировать».

Какой способ выбрать

Если сбой у одного человека, а у остальных всё работает, проблема почти всегда локальная. Серверный кэш в таком случае не трогайте: вы остановите работу всем ради ошибки одного.

Как понять, что кэш действительно виноват

Проверьте два признака. Первый: в другом профиле Linux или на другой машине та же база работает нормально. Второй: после переименования папки базы (mv <GUID> <GUID>.old) проблема исчезает. Переименование безопаснее удаления: если не помогло, возвращаете папку обратно, и ничего не потеряно.

Как очистить кэш 1С на сервере Linux

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

Для кластерного сервера: что лежит в каталоге кластера

В каталоге /home/usr1cv8/.1cv8/1C/1cv8/ у кластера есть:

• 📁 папка reg_<порт> (например, reg_1541) — реестр кластера с настройками, списком баз и служебными файлами;
• 📁 подпапки с именами вида snccntx… — данные сеансов;
• 📄 файлы 1cv8wsrv.lst и другие списки — реестр рабочих серверов.

Удалять reg_* целиком нельзя: пропадут настройки кластера и список зарегистрированных баз. Для обычной чистки хватает папок сеансов.

Очистка для конкретной базы

Кэш одной информационной базы на сервере — это подпапка с её идентификатором внутри каталога кластера. Идентификатор берите из консоли администрирования кластера или командой утилиты rac:

rac infobase summary list --cluster=<ID кластера>

Остановите службу, удалите только папку нужной базы, запустите службу снова.

Очистка для всех баз

Для полной чистки серверного кэша остановите службу сервера и удалите содержимое папок сеансов во всём каталоге кластера, не трогая reg_*:

sudo systemctl stop srv1cv83
sudo find /home/usr1cv8/.1cv8/1C/1cv8/ -maxdepth 2 -type d -name 'snccntx*' -exec rm -rf {} +
sudo systemctl start srv1cv83

Название службы зависит от установки: srv1cv83 — типичное для платформы 8.3, но проверьте у себя: systemctl list-units | grep -i 1c. Права администратора нужны на каждом шаге, поэтому sudo.

Что делать, если после очистки кэша 1С не запускается

Чаще всего виноваты права на файлы или остановленная служба. Разберите по таблице.

После любых ручных операций на сервере приводите права к исходному виду:

sudo chown -R usr1cv8:grp1cv8 /home/usr1cv8/.1cv8

Если владельца в вашей системе зовут иначе (проверьте ls -l /home/usr1cv8/), подставьте реальные имена.

Есть ли разница между Бухгалтерией, ЗУП и ERP

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

• 🧮 Бухгалтерия. Чаще всего проблемы после обновления релиза: старые формы документов, не обновились регламентные отчёты;
• 👥 ЗУП. Тяжёлые справочники сотрудников делают кэш объёмным, а первый вход после чистки — долгим;
• 🏭 ERP. Много подсистем и расширений: кэш растёт быстро, при проблемах с расширениями помогает чистка плюс перезапуск сеансов.

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

Автоматизация очистки: скрипт для cron

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

#!/bin/bash
# /usr/local/bin/clean-1c-cache.sh
set -euo pipefail

# --- пути к сервису и кэшу ---
SERVICE="srv1cv83"
CLUSTER_DIR="/home/usr1cv8/.1cv8/1C/1cv8"
OWNER="usr1cv8:grp1cv8"
LOG="/var/log/clean-1c-cache.log"

# --- функция логирования ---
log() { echo "$(date '+%F %T') $*" >> "$LOG"; }

# --- остановка сервисов ---
log "stop $SERVICE"
systemctl stop "$SERVICE"

# --- очистка кэша ---
log "clean sessions cache"
find "$CLUSTER_DIR" -maxdepth 2 -type d -name 'snccntx*' -exec rm -rf {} +
find /tmp -maxdepth 1 -name 'v8_*' -mtime +1 -delete

# --- проверка и восстановление прав ---
chown -R "$OWNER" "$(dirname "$CLUSTER_DIR")"

# --- запуск сервисов ---
systemctl start "$SERVICE"
sleep 5
systemctl is-active --quiet "$SERVICE" && log "ok" || log "FAIL: service not active"

Сделайте файл исполняемым (chmod +x) и запускайте по расписанию в ночное окно, например раз в неделю:

0 3 * * 0 /usr/local/bin/clean-1c-cache.sh

Правила, которые уберегут от неприятностей:

1. Первые запуски выполняйте вручную и смотрите лог.
2. Скрипт не должен работать, пока идёт резервное копирование баз: разнесите задачи по времени.
3. Если в кластере есть сеансы, которые нельзя прерывать, добавьте проверку списка сеансов и пропуск запуска.
4. Уведомляйте себя о сбое: при FAIL отправляйте сообщение в мессенджер или на почту.

Как не дать кэшу снова разрастись

Чистка лечит последствия, а причину лучше убрать. Три привычки, которые заметно сокращают объём мусора:

• 📏 раз в месяц смотрите размер каталога командой du -sh ~/.1cv8 и на сервере, и на рабочих станциях: рост вдвое за квартал — повод разобраться;
• 🗑 удаляйте кэш баз, которыми больше не пользуетесь: тестовые копии и старые базы оставляют после себя папки, которые никто не чистит;
• 🔄 после каждого обновления платформы закрывайте сеансы и перезапускайте клиент, а не оставляйте его висеть неделями.

Если домашний каталог лежит на небольшом разделе, перенесите его на диск побольше или смонтируйте отдельный том под /home. Тогда переполнение кэша не уронит систему целиком.

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