Ситуация, когда пользователь закрыл программу 1С, в диспетчере задач на терминальном сервере процессы 1cv8.exe отсутствуют, но в консоли администрирования серверов 1С сеанс продолжает отображаться как активный, является классической проблемой для системных администраторов. Это явление часто называют «фантомными» или «зависшими» сеансами. Такие сеансы могут неоправданно занимать лицензии и блокировать регламентные операции. Рассмотрим подробно, почему это происходит и как с этим бороться.
Прежде всего, разберем различие между клиентским сеансом и сеансом фонового задания. Как справедливо отмечено в обсуждении, фоновые и регламентные задания выполняются на стороне сервера. Проанализируем ситуацию: если вы видите в консоли активный сеанс под именем пользователя, который уже вышел, это не всегда означает «зависшее» окно программы.
Часто конфигурации 1С запускают фоновые задачи от имени текущего пользователя (например, при заполнении каких-либо отчетов или выполнении длительных операций). В этом случае в колонке «Приложение» консоли администрирования будет указано Фоновое задание, а не Тонкий клиент. Выясним причину: такие процессы не отображаются в диспетчере задач пользователя на терминальном сервере, так как они физически исполняются внутри рабочего процесса сервера 1С — rphost.exe. Контролировать такие процессы поможет мониторинг ошибок и фоновых заданий 1С.
Если сеанс действительно является клиентским, но «висит» в консоли часами, нам необходимо рассмотреть настройки самого кластера 1С. В свойствах локального кластера существуют важные параметры, регулирующие «время жизни» подозрительных соединений. Разберем их по шагам:
Нас интересуют следующие настройки:
Проанализируем состояние колонки Спящий в списке сеансов — для этого подойдёт универсальный инструмент для администрирования сеансов 1С. Если в этой колонке стоит значение Нет, а клиент фактически закрыт, значит, сервер 1С считает соединение «живым». Это может происходить из-за особенностей сетевого взаимодействия.
Важный нюанс: Консоль администрирования 1С не всегда обновляет данные в реальном времени. Прежде чем приступать к радикальным мерам, выполните ручное обновление списка (клавиша F5 или кнопка «Обновить»), чтобы убедиться, что вы видите актуальную картину, а не кэшированные данные.
Одной из скрытых причин зависания сеансов является некорректная работа сетевых сокетов. Если клиентская сессия (например, RDP) была прервана аварийно, сервер 1С может не получить пакет о закрытии TCP-соединения. Рассмотрим, как заставить операционную систему быстрее выявлять такие «мертвые» соединения.
Для этого необходимо внести изменения в реестр Windows на сервере, где запущен ragent.exe:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.300000 (это 5 минут в миллисекундах).1000 (1 секунда).После этого операционная система начнет гораздо чаще проверять активность открытых сокетов и, если подтверждение от клиента не придет, разорвет соединение, что позволит серверу 1С корректно закрыть сеанс.
Иногда процесс 1cv8.exe закрывается, но серверный объект сеанса остается в памяти из-за программных ошибок в самой конфигурации. Проанализируем ситуацию: в процедурах ПередЗавершениемРаботыСистемы или ПриЗавершенииРаботыСистемы могут быть прописаны вызовы внешних компонентов или модальные окна, которые не дают сеансу корректно «распрощаться» с сервером.
Посмотрим на пример логики, которая может вызвать проблемы:
Процедура ПриЗавершенииРаботыСистемы()
// Если здесь происходит обращение к недоступному COM-объекту
// или зависшему оборудованию, сеанс на сервере может остаться активным.
ЗаписатьСтатистикуВнешнюю();
КонецПроцедуры
В этом случае рекомендуется проверить Журнал регистрации на наличие ошибок в момент выхода пользователей из системы. Если ошибок нет (как в описанном случае на форуме), это косвенно подтверждает «аварийный» характер разрыва связи, когда 1С просто не успевает ничего записать в лог.
Если стандартные методы не помогают, и список сеансов забит «призраками», которые не удаляются даже вручную через консоль, придется рассмотреть метод очистки файлов сеансовых данных. Выясним, где они хранятся.
В каталоге данных кластера (по умолчанию это C:\Program Files\1cv8\srvinfo\reg_1541) есть подпапка snccntxt. В ней хранятся временные данные о текущих сеансах.
Порядок действий:
snccntxt.Внимание: Эта процедура принудительно завершит работу всех пользователей, поэтому ее следует выполнять только в технологическое окно.
Чтобы не мониторить консоль вручную, администраторы часто используют автоматизацию. Рассмотрим возможность использования COM-соединения для принудительного завершения «старых» сеансов — для этого подойдёт обработка автоматического завершения сеансов пользователей в 1С. Разберем пример логики скрипта, который можно запускать по расписанию:
$Connector = New-Object -ComObject "V83.COMConnector"
$ServerAgent = $Connector.ConnectAgent("ИмяСервера")
$Clusters = $ServerAgent.GetClusters()
$Cluster = $Clusters[0]
$ServerAgent.Authenticate($Cluster, "", "")
$Sessions = $ServerAgent.GetSessions($Cluster)
foreach ($Session in $Sessions) {
# Проверяем время последней активности
$IdleTime = (Get-Date) - $Session.LastActiveAt
If ($IdleTime.TotalMinutes -gt 120) {
$ServerAgent.TerminateSession($Cluster, $Session)
}
}
Используя объект V83.COMConnector, мы можем программно анализировать время последней активности сеанса (LastActiveAt) и, если оно превышает разумные пределы (например, 2 часа), принудительно вызывать метод TerminateSession. Это гарантированно очистит список от зависших соединений, которые по какой-то причине проигнорировали настройки таймаутов в самом кластере.