Как сбросить зависшие сеансы 1С

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

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

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

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

Прежде чем удалять сеанс, убедитесь, что он именно завис, а не принадлежит работающему пользователю. Характерные признаки: пользователь утверждает, что программа давно закрыта, но в списке активных сеансов его запись присутствует; время последнего вызова (активности) сеанса устарело на десятки минут или часы; объём прочитанных и записанных данных не меняется при повторном обновлении списка.

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

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

Сброс сеансов через консоль кластера серверов 1С

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

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

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

1. 1
   Откройте консоль «Администрирование серверов 1С Предприятия»
2. 2
   Разверните кластер и перейдите в раздел «Сеансы»
3. 3
   Найдите зависший сеанс по пользователю и времени последнего вызова
4. 4
   Убедитесь, что пользователь действительно не работает
5. 5
   Удалите сеанс и проверьте, что блокировки сняты
6. 6
   При необходимости включите блокировку начала сеансов для базы

Что делать в файловом режиме работы

В файловой базе нет кластера серверов, поэтому сеанс существует, пока жив клиентский процесс или открыто сетевое подключение к файлу базы. Если пользователь утверждает, что вышел, а запись о нём осталась (видно, например, в списке активных пользователей конфигуратора), сначала проверьте его компьютер: возможно, процесс 1cv8.exe завис в диспетчере задач. Завершите процесс штатно через «Снять задачу».

Если компьютер пользователя выключен или недоступен, а база размещена в сетевой папке, зависшее подключение может держать SMB-сессию на файловом сервере. Откройте на сервере «Управление компьютером» → «Общие папки» → «Сеансы» и закройте сессию нужного пользователя, либо используйте команду net session для просмотра и завершения сессий.

Имейте в виду: в файловом режиме некорректное обрывание соединения во время записи повышает риск повреждения файла 1Cv8.1CD. Перед любыми принудительными действиями убедитесь, что есть актуальная резервная копия.

Сброс сеансов из конфигуратора и встроенными средствами

В конфигураторе доступен просмотр активных пользователей: меню «Администрирование» → «Активные пользователи». Список показывает сеансы и соединения, но штатной кнопки принудительного завершения чужого сеанса здесь нет — конфигуратор позволяет только наблюдать. Для сброса используйте консоль кластера или программные средства.

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

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

Автоматизация: PowerShell и RAC

Для регулярных операций удобна утилита командной строки RAC из состава сервера 1С. Она позволяет получить список сеансов и завершить конкретный сеанс по его идентификатору, что легко обернуть в скрипт для планировщика задач.

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

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

Альтернатива — PowerShell-модуль, работающий с COM-объектом V83.COMConnector или с RAC через вызовы командной строки. Выбор инструмента зависит от того, что уже используется в инфраструктуре; принципиальной разницы в результате нет.

Если сброс не помогает: радикальные меры

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

Если проблема на стороне СУБД (MS SQL, PostgreSQL), зависшие соединения видны и там. В MS SQL их можно посмотреть через Activity Monitor и завершить командой KILL по идентификатору процесса. Однако сначала завершайте сеанс на уровне кластера 1С — тогда сервер СУБД корректно откатит транзакцию.

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

Проверка результата и профилактика

После сброса сеанса убедитесь, что проблема решена: обновите список сеансов в консоли — записи не должно быть; попробуйте установить монопольный режим или запустить операцию, которая блокировалась; попросите пользователя войти заново, если ошибка была на его стороне.

Для профилактики настройте в свойствах информационной базы параметры завершения неактивных сеансов: «Время засыпания пассивного сеанса» и «Время завершения спящего сеанса». Это штатный механизм кластера, который автоматически усыпляет и затем завершает сеансы без активности, снижая количество «призраков».

Дополнительно: отключите гибернацию на рабочих станциях, настройте корректный таймаут на сетевом оборудовании и VPN, а для ночных регламентных операций используйте автоматическую блокировку сеансов по расписанию.

Частые ошибки при сбросе сеансов

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

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

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