Каждый системный администратор или разработчик 1С рано или поздно сталкивается с ситуацией, когда при попытке обновить конфигурацию базы данных система выдает сообщение о наличии активных соединений. При этом в консоли администрирования кластера список сеансов пуст, а блокировки на вход установлены. Проблема часто кроется в механизме хранения сеансовых данных и файлах вида snccntx*.dat. В этой статье мы подробно разберем, что это за данные, почему они «зависают» и как эффективно очистить кластер без полной остановки всех сервисов.
Для начала выясним причину появления этих файлов. В каталоге реестра кластера 1С (обычно это C:\Program Files\1cv8\srvinfo\reg_1541) создаются файлы с расширением .dat и префиксом snccntx. Проанализируем их назначение: они представляют собой бинарное хранилище состояния конкретного сеанса. В отличие от базы данных SQL, где хранятся прикладные данные, в этих файлах фиксируется оперативное состояние окружения пользователя.
Рассмотрим подробнее, что находится внутри этих файлов:
ПараметрыСеанса, которые задаются при старте системы.Важно понимать, что эти файлы используют проприетарный бинарный формат 1С на основе внутренней сериализации. Прочитать их обычными NoSQL-менеджерами или текстовыми редакторами невозможно, так как данные упакованы в специфическую структуру объектов платформы.
Разберем ситуацию: почему сеансов в консоли нет, а соединения в базе SQL или в оснастке кластера остаются? Это происходит из-за разделения ответственности внутри кластера. За логический сеанс отвечает менеджер кластера (rmngr), а за физическое соединение с СУБД — рабочий процесс (rphost). Если клиентское приложение завершилось аварийно, менеджер может удалить запись о сеансе, но рабочий процесс продолжает удерживать соединение и файл snccntx на диске.
Проанализируем механизм блокировки: при обновлении конфигурации 1С пытается получить монопольный доступ. Если в реестре кластера или на диске числится активный файл сеансовых данных, система считает, что работа продолжается, и блокирует обновление, даже если физического процесса пользователя уже не существует.
Это самый эффективный метод, позволяющий избежать остановки всей службы кластера, что особенно критично, если на сервере крутятся десятки других баз. Рассмотрим пошаговый алгоритм:
PID (идентификатор процесса) этого rphost.Resource Monitor.rphost.exe с соответствующим PID и завершим его принудительно (End Process).После этого rmngr обнаружит пропажу рабочего процесса и автоматически очистит связанные с ним записи в реестре и временные файлы сеансов. Посмотрим на ситуацию глазами системы: при следующем обновлении консоли соединение исчезнет, и путь для обновления конфигурации будет открыт.
Если точечное завершение процессов не помогает (например, когда rmngr «зациклился» на файлах), придется прибегнуть к радикальному методу. Разберем, почему простое удаление файлов snccntx без остановки службы часто бесполезно: менеджер кластера держит карту этих файлов в оперативной памяти. Если удалить файл «на лету», система все равно будет помнить о нем до момента перезапуска.
Рассмотрим правильную последовательность действий:
rphost, rmngr и ragent завершены. Если они зависли — завершим их вручную.srvinfo\reg_1541\snccntx...)..dat. Важно: не удаляйте файл 1CV8Reg.lst, так как в нем хранятся настройки списка баз и пользователей кластера.После этой процедуры сервер 1С создаст чистую карту сеансов, и все фантомные соединения гарантированно исчезнут.
Существует еще один изящный метод, который позволяет минимизировать простой. Разберем его по шагам:
Нет.Kill Task в операционной системе.Этот метод позволяет изолировать «проблемные» соединения в рамках одного rphost и уничтожить их, не прерывая работу других пользователей.
Если мы хотим точно выяснить, какой файл мешает работе, воспользуемся утилитой Resource Monitor (Монитор ресурсов) в Windows. Проанализируем вкладку «Диск» или «Сеть»:
snccntx.srvinfo в исключения антивируса.Для автоматизации процесса можно использовать встроенные возможности платформы. Рассмотрим пример кода на языке 1С, который позволяет программно разорвать соединения (хотя против «фантомных» соединений в ОС это помогает не всегда, это хороший первый шаг):
// Пример программного завершения соединений информационной базы
Процедура ЗавершитьСеансыИнформационнойБазы()
СоединениеСКластером = Новый COMОбъект("V83.COMConnector");
AgentConnection = СоединениеСКластером.ConnectAgent("ServerName");
Clusters = AgentConnection.GetClusters();
Для Каждого ТекущийКластер Из Clusters Цикл
AgentConnection.Authenticate(ТекущийКластер, "", "");
РабочиеПроцессы = AgentConnection.GetWorkingProcesses(ТекущийКластер);
// Перебор процессов и поиск нужной базы
// Логика удаления соединений через метод TerminateConnection
КонецЦикла;
КонецПроцедуры
В современных версиях платформы (8.3.15+) рекомендуется использовать утилиту rac (Remote Administration Console), которая работает через ras (сервер администрирования). Она позволяет более «жестко» подавать команды кластеру на удаление соединений, минуя графическую консоль MMC, которая иногда может отображать недостоверную информацию из-за кэширования.
Подведем итог: файлы snccntx — это критически важная часть инфраструктуры 1С, отвечающая за сохранение состояния сеанса. Основной способ борьбы с их «зависанием» — это идентификация проблемного рабочего процесса rphost через PID и его принудительное завершение, либо полная очистка кэша сеансовых данных при остановленной службе сервера.