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

Некорректное завершение работы может привести к потере несохраненных данных пользователем или даже к повреждению таблиц базы данных, если прервать запись в критический момент. Поэтому администратор должен четко понимать разницу между штатным отключением и аварийным разрывом соединения. В этой статье мы детально разберем все доступные методы управления активными подключениями.

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

Анализ текущей активности в журнале регистрации

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

Журнал позволяет отфильтровать события по типу «Сеанс» и увидеть время начала работы, компьютер пользователя и имя приложения. Это дает полное представление о том, кто именно занимает ресурсы базы. Если вы заметили сеанс, который висит в статусе «Активен» уже несколько часов без движения, это первый кандидат на проверку.

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

⚠️ Внимание: Перед отключением пользователя убедитесь, что он не выполняет длительную обработку, такую как расчет зарплаты или формирование сложных отчетов, так как прерывание приведет к потере результатов работы.
💡

Используйте фильтр по событию "Сеанс" в журнале регистрации, чтобы быстро найти ID конкретного подключения для последующего анализа в консоли администрирования.

Управление через Консоль администрирования серверов 1С

Наиболее цивилизованным и рекомендуемым способом управления соединениями в клиент-серверном варианте работы является использование Консоли администрирования серверов 1С:Предприятие. Этот инструмент позволяет взаимодействовать с кластером серверов на глубоком уровне, предоставляя полный контроль над инфобазой.

Для начала работы необходимо запустить консоль и подключиться к центральному серверу 1С. В дереве объектов нужно раскрыть узел «Информационные базы», найти нужную базу и перейти в раздел «Сеансы». Здесь отображается список всех активных подключений в реальном времени с детальной информацией о каждом из них.

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

  • 🔍 Позволяет видеть IP-адреса и имена компьютеров подключенных клиентов.
  • 🛑 Дает возможность завершать сеансы выборочно или массово.
  • ⚙️ Предоставляет доступ к блокировкам и соединениям с СУБД.

Важно отметить, что для работы с консолью требуются права администратора кластера. Если у вас нет этих прав, данный метод будет недоступен. Также стоит учитывать, что в распределенных кластерах список сеансов может обновляться с небольшой задержкой.

📊 Какой вариант 1С вы используете чаще всего?
Файловый
Клиент-серверный
Веб-клиент
Мобильное приложение

Закрытие сеансов из интерфейса Предприятия

Если у администратора нет доступа к серверу, но есть полные права внутри самой конфигурации 1С:Предприятие, можно воспользоваться встроенными средствами. В типовой конфигурации «Администрирование системы» часто доступен раздел «Монитор пользователей» или аналогичный инструмент.

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

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

Запрос.Текст = "ВЫБРАТЬ Сеансы.Ссылка КАК Ссылка

|ИЗ ИнформационнаяБаза.Сеансы КАК Сеансы

|ГДЕ Сеансы.Завершить = ИСТИНА";

Результат = Запрос.Выполнить();

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

☑️ Проверка перед отключением

Выполнено: 0 / 4

Использование монопольного режима для блокировки

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

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

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

Метод Требуемые права Риск потери данных Скорость выполнения
Консоль сервера Админ кластера Низкий Высокая
Интерфейс 1С Полные права Средний Средняя
Монопольный режим Конфигуратор Низкий Зависит от пользователей
Лицензионный сервер Админ HASP/USB Высокий Мгновенная
⚠️ Внимание: Включение монопольного режима в рабочее время может парализовать работу отдела, поэтому согласовывайте такие действия с руководством заранее.

Управление через лицензионный менеджер HASP

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

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

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

Последствия сброса лицензии

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

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

Аварийное завершение процессов на уровне ОС

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

Для реализации этого метода администратор должен иметь доступ к серверу по RDP или через консоль. Необходимо идентифицировать процесс, принадлежащий конкретному пользователю. Это можно сделать через Диспетчер задач или утилиты командной строки, сопоставив ID процесса с ID сеанса в базе.

Завершение процесса на уровне ОС равносильно выдергиванию шнура питания из компьютера пользователя. Транзакции, открытые в момент убийства процесса, не будут откатаны автоматически на уровне СУБД, что может потребовать последующего анализа целостности данных. Используйте этот метод только если база перестала отвечать полностью.

  • 💀 Гарантированно освобождает ресурсы, даже если 1С "мертва".
  • ⚠️ Высокий риск повреждения таблиц временных хранилищ.
  • 🔧 Требует прав локального администратора на сервере.
⚠️ Внимание: Завершение процесса rphost может привести к тому, что СУБД (PostgreSQL или MS SQL) будет считать транзакцию открытой долгое время, блокируя другие операции. Требуется проверка активных транзакций в СУБД.
💡

Завершение процессов на уровне ОС — это крайняя мера, которую следует применять только при полной недоступности штатных инструментов администрирования.

Программное завершение через внешнюю обработку

Для автоматизации процесса закрытия сеансов разработчики часто создают специальные внешние обработки. Такие скрипты подключаются к базе в монопольном режиме и программно проходят по списку сеансов, вызывая метод Завершить() для каждого объекта.

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

Пример кода для внешней обработки может выглядеть следующим образом:

Сеансы = ПолучитьМенеджерСеансов();

Для Каждого Сеанс Из Сеансы Цикл

Если Сеанс.Пользователь <> "Администратор" Тогда

Попытка

Сеанс.Завершить();

Исключение

ЗаписьЖурналаРегистрации(...);

КонецПопытки;

КонецЕсли;

КонецЦикла;

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

💡

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

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

Можно ли закрыть сеанс пользователя, который находится в режиме предприятия, не заходя на сервер?

Да, если у вас есть права администратора в самой базе 1С. Вы можете использовать обработку «Монитор пользователей» или написать простой скрипт, который завершит сеанс. Однако, если пользователь завис намертво и не отвечает на сигналы сервера, без доступа к консоли сервера или диспетчеру задач ОС обойтись не получится.

Что произойдет с данными, если я принудительно закрою сеанс во время проведения документа?

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

Как узнать, какой именно процесс rphost соответствует какому пользователю?

Прямого соответствия в Диспетчере задач Windows часто не видно, так как процессы обезличены. Самый надежный способ — посмотреть ID сеанса в Консоли администрирования серверов 1С, а затем сопоставить его с PID процесса через утилиты мониторинга или логи сервера 1С.

Почему после закрытия сеанса лицензия не освобождается сразу?

Лицензионный менеджер может удерживать лицензию еще некоторое время (обычно до 5-10 минут) на случай переподключения клиента при кратковременном разрыве сети. Если лицензия не возвращается долгое время, возможно, процесс на клиенте не был завершен корректно и требует ручного убийства.