Как удалить зависшие сеансы 1С

Зависший сеанс 1С — это подключение пользователя, которое фактически не работает, но продолжает удерживать соединение с сервером, лицензии и блокировки данных. Типичные симптомы: пользователь не может войти в базу из-за сообщения о занятой лицензии, документы заблокированы «несуществующим» сотрудником, а регламентные задания не выполняются, потому что фоновый процесс завис. Проблема особенно актуальна в клиент-серверных базах, где сеансы управляются агентом сервера 1С, а не локальным приложением.

Причины зависания обычно одни и те же: аварийное закрытие клиента (обрыв сети, выключение компьютера кнопкой питания, снятие процесса через диспетчер задач), ошибки в коде, приводящие к бесконечному циклу фонового задания, а также проблемы на стороне СУБД. Агент сервера 1С сам удаляет «мёртвые» сеансы, но делает это с задержкой — по умолчанию проверка активности занимает заметное время, поэтому администратору часто приходится вмешиваться вручную.

Ниже разобраны рабочие способы найти и удалить зависшие сеансы: через консоль кластера серверов 1С, через панель управления IIS и СУБД, через командную строку rac и пакетные сценарии. Отдельно рассмотрены риски принудительного завершения и способы снизить количество зависаний в будущем.

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

Прежде чем что-то удалять, убедитесь, что сеанс неактивен, а не выполняет длительную операцию. Проведение большого документа, закрытие месяца или формирование тяжёлого отчёта внешне выглядят так же, как зависание: клиент «не отвечает», сеанс держит блокировки. Принудительное завершение такого процесса оборвёт транзакцию и приведёт к потере несохранённых данных.

Признаки настоящего зависания: в консоли кластера у сеанса по колонке активности видно, что он не вызывал сервер длительное время; пользователь подтверждает, что его клиент закрыт или компьютер перезагружался; соединение с СУБД находится в состоянии ожидания без выполняемого запроса. Если пользователь утверждает, что программа у него работает — сеанс трогать нельзя.

Удаление сеансов через консоль кластера серверов 1С

Основной и самый безопасный инструмент — консоль администрирования серверов 1С (MMC-оснастка «Администрирование серверов 1С Предприятия» на Windows или server console на Linux). Она работает с агентом сервера напрямую, поэтому удаление сеанса здесь корректно освобождает лицензию и инициирует откат транзакций на стороне СУБД.

Порядок действий: откройте консоль, разверните нужный кластер и рабочий сервер, перейдите в ветку информационной базы и выберите пункт «Сеансы». В списке найдите зависшее подключение — ориентируйтесь на имя пользователя, приложение (толстый клиент, тонкий клиент, фоновое задание) и время последней активности. Выделите сеанс и нажмите «Удалить» в контекстном меню или на панели инструментов.

1. 1
   Откройте консоль администрирования серверов 1С под учётной записью администратора кластера
2. 2
   Разверните кластер → рабочий сервер → информационную базу → ветку «Сеансы»
3. 3
   Отсортируйте список по пользователю или времени активности и найдите зависший сеанс
4. 4
   Убедитесь, что клиент пользователя действительно закрыт
5. 5
   Выделите сеанс и нажмите «Удалить», подтвердите действие
6. 6
   Проверьте, что сеанс исчез из списка, а лицензия освободилась

Если зависло фоновое задание, ищите сеанс с соответствующим типом приложения. Удаление такого сеанса прерывает задание, но само регламентное задание останется включённым и запустится по расписанию снова — если причина зависания в коде, ситуация повторится. В этом случае сначала выясните, на каком объекте задание зациклилось.

Удаление сеансов через командную строку (rac)

Когда графическая консоль недоступна (например, работа ведётся по SSH на Linux-сервере) или нужно удалять сеансы пакетно, используется консольная утилита rac из состава сервера 1С. Она находится в каталоге bin установленной версии платформы и требует знания идентификатора кластера и сеанса.

Сначала получите список сеансов, затем удалите нужный по его UUID. Команды выполняются от имени пользователя с правами администратора кластера.

rac session --cluster=<ID_кластера> list --infobase=<ID_базы>
rac session --cluster=<ID_кластера> terminate --session=<ID_сеанса>

Утилита rac удобна для автоматизации: можно написать скрипт, который периодически получает список сеансов и завершает те, что неактивны дольше заданного порога. Такой подход применяют, когда пользователи массово оставляют открытые клиенты на ночь и лицензии заканчиваются к утру. Однако автоматическое завершение должно учитывать только действительно простаивающие сеансы, иначе скрипт начнёт «убивать» работающих пользователей.

Завершение соединений на стороне СУБД

Если консоль кластера недоступна или сеанс «не удаляется» штатными средствами, крайняя мера — завершить соответствующее соединение на стороне СУБД. В Microsoft SQL Server это делается через Activity Monitor в SQL Server Management Studio или командой KILL с номером SPID. В PostgreSQL — функцией pg_terminate_backend с PID нужного процесса, предварительно найдя его в представлении pg_stat_activity.

Этот способ требует осторожности: СУБД оперирует соединениями, а не сеансами 1С, и по ошибке можно завершить чужое рабочее подключение. Ориентируйтесь на имя приложения и логин, под которым сервер 1С подключается к базе, а также на время последнего запроса. После завершения соединения агент сервера 1С обнаружит обрыв и удалит сеанс из своего списка.

Зависшие сеансы в файловых базах

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

Штатный способ — открыть базу в конфигураторе и посмотреть список активных пользователей через меню «Администрирование → Активные пользователи». Оттуда зависшее подключение можно попробовать завершить. Если войти не получается, убедитесь, что ни у кого из пользователей реально не открыт клиент, и проверьте наличие зависших процессов 1cv8.exe на компьютерах пользователей — их завершение через диспетчер задач освобождает блокировку.

Как проверить результат и снизить число зависаний

После удаления сеанса проверьте три вещи: сеанс исчез из списка в консоли кластера, пользователь смог войти в базу (лицензия освободилась), а ранее заблокированные объекты стали доступны для редактирования. Если блокировка осталась — вероятно, её держит другой сеанс или незавершённая транзакция на СУБД, ищите источник дальше.

Чтобы зависания повторялись реже, настройте в свойствах информационной базы в консоли кластера параметры «интервал перезапуска» и «допустимый объём памяти» рабочих процессов — это заставит сервер периодически пересоздавать процессы и сбрасывать накопившиеся проблемы. Также полезно ограничить время простоя сеансов: в свойствах базы можно задать завершение неактивных сеансов по таймауту. Дополнительно проверьте стабильность сети между клиентами и сервером — обрывы соединения являются главной причиной «осиротевших» сеансов.

Типичные ошибки при удалении сеансов

Самая частая ошибка — завершение сеанса без проверки, работает ли пользователь. Сообщение «программа не отвечает» у клиента не всегда означает зависание: возможно, идёт тяжёлая операция, и через несколько минут она завершится. Второй типичный просчёт — завершение процесса rphost или всего агента сервера вместо отдельного сеанса: это обрывает работу всех пользователей базы и уместно только при полном зависании сервиса.

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

Часто задаваемые вопросы