В процессе администрирования и обновления информационных баз 1С:Предприятия в клиент-серверном варианте нередко возникает ситуация: список активных пользователей в консоли администрирования пуст, соединения на сервере СУБД отсутствуют, однако при попытке применить изменения конфигурации Конфигуратор выдает ошибку о наличии активных сеансов или монопольной блокировки. Разберем причины возникновения таких фантомных блокировок и рассмотрим несколько практических способов их устранения — как с полной остановкой служб, так и в режиме «горячего» исправления на работающем сервере.
В архитектуре клиент-серверной платформы 1С за учет активных сеансов и распределение транзакционных блокировок отвечает менеджер кластера (rmngr), а выполнение операций пользователей происходит внутри рабочих процессов (rphost). Проанализируем, почему блокировка может остаться активной при отсутствии видимого сеанса:
rphost может освободить подключение к СУБД, однако менеджер кластера rmngr сохраняет информацию о монопольной блокировке во внутреннем кэше и сеансовых файлах.snccntx). При некорректном завершении процессов эти файлы не очищаются, что приводит к удержанию блокировки при повторном старте.Если сервер является рабочим (боевым) и на нем параллельно работают пользователи в других базах, перезапускать всю службу сервера приложений нежелательно. В этом случае применим методику ротации процессов rphost через консоль администрирования кластера:
60 секунд.rphost, на которые постепенно перенаправляются все живые сеансы и активные соединения.rphost.rphost.exe по их идентификаторам (PID). Вместе с ними принудительно освобождаются удерживаемые блокировки.0 (или устанавливаем регламентное значение для регулярной профилактики).Когда фантомная блокировка привязана к конкретной базе данных, а остальные информационные базы на сервере трогать нельзя, эффективен метод перерегистрации описания базы в кластере:
Если регламент обслуживания позволяет перезапустить службы сервера 1С, наиболее надежным способом является остановка процессов и удаление временных файлов сеансовых данных из каталога srvinfo. Все данные о блокировках хранятся в подпапках вида snccntx* внутри каталога реестра кластера (по умолчанию путь: C:\Program Files\1cv8\srvinfo\reg_1541).
Рассмотрим автоматизированный командный скрипт (батч-файл), выполняющий корректную остановку служб, гарантированное завершение зависших процессов и очистку временных контекстов блокировок:
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="C:\Program Files\1cv8\srvinfo\reg_1541"
set PFL_PATH="C:\ProgramData\1C\1cv8"
set TEMP_PATH="C:\Windows\Temp"
sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout /t 5
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout /t 5
DEL /Q /F /S "%CNTX_PATH%\snccntx*"
DEL /Q /F "%PFL_PATH%\*.pfl"
DEL /Q /F /S "%TEMP_PATH%\*.*"
sc start %SERVICE_1C_NAME%
sc start %SERVICE_RAS_NAME%
Обратите внимание: удаление файлов snccntx* при работающей службе ragent заблокировано операционной системой, поэтому процедура выполняется строго после остановки сервера 1С.
Иногда зависшие сеансы перестают отображаться в графической оснастке MMC, но остаются доступными для управления через протокол RAS. В такой ситуации используем консольную утилиту rac:
rac session --cluster=<Идентификатор_Кластера> listsession) проблемной базы.
rac session --cluster=<Идентификатор_Кластера> terminate --session=<Идентификатор_Сеанса>
Для минимизации подобных сбоев на рабочем сервере рекомендуется выполнить следующие настройки:
1200 секунд) и Время завершения спящих сеансов (например, 120 секунд). Это заставит кластер автоматически уничтожать неактивные подключения./uc), что исключит подключение фоновых заданий во время обновления конфигурации.