Как гарантированно завершить зависшие и не спящие сеансы в 1С 8.3 для монопольного доступа

← На главную

При обслуживании информационных баз 1С часто возникает задача перевести базу в монопольный режим в ночное время — например, для создания резервной копии, выполнения регламентных процедур или обновления конфигурации. Администраторы, перешедшие с платформы 8.2 на 8.3, нередко сталкиваются с ситуацией, когда привычный перезапуск службы сервера 1С больше не сбрасывает клиентские подключения. Клиенты не переходят в спящий режим, а после рестарта службы продолжают удерживать монопольный доступ. Разберем архитектурные причины такого поведения платформы 1С:Предприятие 8.3 и рассмотрим проверенные технические способы гарантированного завершения всех пользовательских сеансов.

Выясним причину: почему сеансы не засыпают и восстанавливаются

Проанализируем ситуацию, которая происходит при попытке сбросить сеансы простой остановкой службы ragent. В платформе 8.3 реализован развитый механизм отказоустойчивости кластера, призванный защитить пользователей от кратковременных сбоев сети и перезапусков рабочих процессов. Это кардинально отличает поведение 8.3 от 8.2:

Сохранение контекста сеансов на сервере. Кластер серверов 1С сохраняет состояние сеансов на жесткий диск в служебный каталог реестра кластера (каталоги вида snccntx_* внутри папки srvinfo). При остановке и повторном запуске службы клиенты не отваливаются сразу: тонкий и толстый клиент переходят в режим ожидания связи и отправляют повторные запросы. Как только сервер запускается, контекст считывается из файлов, и сеансы восстанавливаются без потери данных.
Служебная активность и сброс таймеров сна. Даже если пользователь не нажимает клавиши и не двигает мышь, клиентское приложение обменивается с сервером техническими пакетами: keep-alive проверками, синхронизацией механизма оповещений платформы, системными push-уведомлениями и опросом лицензий. Кроме того, в конфигурациях на базе Библиотеки стандартных подсистем (БСП) работают фоновые обработчики ожидания. Сервер расценивает каждый сетевой пакет как активность, из-за чего счетчик неактивности обнуляется, а параметры засыпания информационной базы не срабатывают.

Способ 1. Программное отключение сеансов через COM-коннектор

Рассмотрим надежный вариант программного завершения работы пользователей через интерфейс администрирования кластера серверов 1С. Для этого мы можем подключиться к агенту кластера через V83.ComConnector, перебрать активные сеансы информационной базы и принудительно завершить их с помощью метода TerminateSession.

Посмотрим на пример реализации на встроенном языке 1С:


Коннектор = Новый COMОбъект("V83.ComConnector");
Сервер = "ИмяСервера1С";
Порт = 1540;

// Подключаемся к агенту кластера
Агент = Коннектор.ConnectAgent(Сервер + ":" + Строка(Порт));
Кластеры = Агент.GetClusters();
Кластер = Кластеры.GetValue(0);

// Аутентификация администратора кластера
Агент.Authenticate(Кластер, "АдминистраторКластера", "Пароль");

// Аутентификация в рабочих процессах
Процессы = Агент.GetWorkingProcesses(Кластер);
Для Каждого Процесс Из Процессы Цикл
    Если Процесс.Running И Процесс.Use Тогда
        Агент.AuthenticateWorkingProcess(Процесс, "АдминистраторКластера", "Пароль");
    КонецЕсли;
КонецЦикла;

// Получаем информационную базу по имени
ИнфоБазы = Агент.GetInfoBases(Кластер);
ЦелеваяБаза = Неопределено;
Для Каждого База Из ИнфоБазы Цикл
    Если ВРег(База.Name) = ВРег("НашаБаза") Тогда
        ЦелеваяБаза = База;
        Прервать;
    КонецЕсли;
КонецЦикла;

Если ЦелеваяБаза <> Неопределено Тогда
    // Авторизуемся в информационной базе
    Агент.AddAuthentication(Кластер, "АдминистраторБазы", "ПарольБазы");

    // Завершаем все сеансы, кроме текущего служебного
    Сеансы = Агент.GetInfoBaseSessions(Кластер, ЦелеваяБаза);
    Для Каждого Сеанс Из Сеансы Цикл
        // Исключаем фоновые подключения администратора консоли
        Если Сеанс.AppID = "SrvrConsole" Или Сеанс.AppID = "COMConsole" Тогда
            Продолжить;
        КонецЕсли;
        
        Попытка
            Агент.TerminateSession(Кластер, Сеанс);
        Исключение
            // Фиксация ошибки при невозможности разорвать сеанс
        КонецПопытки;
    КонецЦикла;
КонецЕсли;

Разберем важные детали работы кода: перед завершением самих соединений базы необходимо отключать именно сеансы (Session). Если попытаться просто разорвать низкоуровневые соединения (Connection), сеанс в ряде версий платформы может зависнуть в состоянии ожидания.

Способ 2. Блокировка соединений и использование утилит RAS и RAC

Если мы не хотим использовать COM-технологию, наиболее современным и рекомендуемым способом является связка сервера администрирования ras и консольной утилиты rac. Данный подход отлично подходит для интеграции в PowerShell или Bash-скрипты ночного обслуживания.

Разберем по шагам правильную процедуру перевода базы в монопольный режим:

Установка блокировки соединений. Перед принудительным завершением сеансов необходимо заблокировать вход для новых пользователей и отключить регламентные задания. Обязательно задаем код разрешения (параметр --permission-code), чтобы наш служебный скрипт мог подключиться монопольно.
Сброс существующих сеансов. Командой утилиты rac session terminate завершаем все открытые сеансы. Поскольку на базе уже активна блокировка, клиентские приложения не смогут выполнить повторное переподключение и закроются с сообщением об ограничении доступа.
Запуск регламентных процедур. Запускаем скрипт обслуживания с ключом командной строки /UC <КодРазрешения> в монопольном режиме (параметр /M).
Снятие блокировки. После завершения ночных работ снимаем флаг блокировки информационной базы через rac, открывая доступ пользователям.

Способ 3. Очистка контекста сеансов при перезапуске службы сервера

Если специфика инфраструктуры требует применения перезапуска системной службы 1C:Enterprise Server Agent (например, для гарантированного устранения фрагментации и утечек оперативной памяти), проанализируем, как нейтрализовать механизм автовосстановления клиентов.

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

Останавливаем службу сервера 1С с помощью команды net stop "1C:Enterprise 8.3 Server Agent".
В каталоге служебных данных кластера (по умолчанию путь выглядит как C:\Program Files\1cv8\srvinfo\reg_1541\) находим все папки, названия которых начинаются с snccntx_.
Удаляем эти каталоги. Важно: ни в коем случае нельзя удалять файлы конфигурации кластера 1CV8Clst.lst, 1CV8Reg.lst и файлы описания информационных баз.
Запускаем службу командой net start "1C:Enterprise 8.3 Server Agent".

Когда служба запустится без сохраненного контекста, клиентские приложения получат ошибку о невозможности восстановить сеанс и аварийно завершат работу процессов 1cv8.exe на рабочих местах пользователей.

Способ 4. Устранение зависаний в терминальной среде (RDP)

Если клиенты работают в терминальном режиме на сервере Windows Server x64, сеансы часто удерживаются процессами операционной системы даже после закрытия окна программы пользователем. Распространенный виновник — процесс splwow64.exe (мост 32-битной подсистемы печати в 64-битной ОС), который запускается при формировании печатных форм и отчетов.

Если пользователь отключил терминальную сессию нажатием на крестик, процесс печати удерживает открытые дескрипторы программы 1С. В результате сеанс в консоли кластера остается в статусе бодрствующего.

Для устранения этой проблемы настроим окружение:

В реестре Windows Server уменьшим время жизни неактивного процесса splwow64.exe (параметр реестра SplWOW64TimeOut в ветке HKLM\SYSTEM\CurrentControlSet\Control\Print).
В групповых политиках терминального сервера (GPO) настроим принудительное завершение отключенных сеансов: Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Узел сеансов удаленных рабочих столов -> Ограничения по времени для сеансов. Зададим таймаут для отключенных (disconnected) сессий не более 15–30 минут.

Способ 5. Завершение работы штатными средствами БСП

Если конфигурация разработана на основе Библиотеки стандартных подсистем, завершение работы пользователей можно делегировать встроенному механизму БлокировкаРаботыПользователей. В подсистеме администрирования присутствует регламентная обработка «Блокировка работы пользователей», которая посылает всем активным клиентам управляемый сигнал на завершение работы программы через системную функцию ЗавершитьРаботуСистемы(Ложь).

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