В процессе администрирования информационных баз платформы 1С:Предприятие часто возникает критическая необходимость принудительно разорвать соединение с пользователем. Ситуации бывают разными: от планового обновления конфигурации и выгрузки базы до зависания сеанса, который блокирует исключительный режим работы. Администраторам необходимо четко понимать архитектуру соединений, чтобы не потерять данные и обеспечить целостность транзакций при разрыве.
Корректное завершение работы требует понимания разницы между клиентским приложением, серверным процессом rmngr и рабочими процессами rphost. Неправильные действия могут привести к повреждению таблиц базы данных или зависанию блокировок. В этой статье мы детально разберем штатные и аварийные методы отключения пользователей, а также проанализируем последствия каждого подхода.
Диагностика активных сеансов через консоль администрирования
Первым шагом перед любым вмешательством является получение полной картины происходящего в кластере серверов. Средство администрирования кластера серверов 1С:Предприятие (расположенное в меню Пуск или в составе дистрибутива платформы) предоставляет исчерпывающую информацию о текущем состоянии системы. Здесь отображаются не только подключенные пользователи, но и технические сеансы, необходимые для работы фоновых заданий.
В окне свойств кластера необходимо перейти в раздел Информационные базы, выбрать нужную базу и открыть вкладку Сеансы. В этом списке отражаются уникальные идентификаторы сеансов (UUID), имена пользователей, компьютеры, с которых выполнено подключение, и время начала сессии. Особое внимание стоит уделить колонке «Приложение», так как она позволяет отличить толстый клиент от тонкого или веб-клиента.
Иногда в списке можно увидеть сеансы со статусом «Ожидание» или заблокированные сессии, которые фактически уже не активны, но формально занимают слот лицензии. Анализ списка сеансов помогает выявить аномалии, например, когда один пользователь имеет десять одновременных подключений, что может свидетельствовать о некорректной работе кода или сетевых проблемах. Перед принудительным завершением рекомендуется попытаться связаться с пользователем для сохранения им открытых документов.
Штатное завершение сеанса через интерфейс администратора
Наиболее безопасным способом отключения пользователя является использование встроенного механизма завершения сеанса непосредственно из консоли администрирования. Этот метод инициирует штатную процедуру закрытия соединения, позволяя платформе 1С:Предприятие корректно завершить текущие транзакции и освободить блокировки на уровне СУБД. Для выполнения операции необходимо выделить нужный сеанс в списке, кликнуть правой кнопкой мыши и выбрать пункт Завершить сеанс.
После подтверждения действия сервер посылает клиентскому приложению сигнал о необходимости прекратить работу. Пользователь увидит стандартное сообщение об ошибке соединения или о том, что сеанс завершен администратором. Важно отметить, что если пользователь в этот момент сохранял сложный документ с проведением по регистрам, операция может быть отменена, и данные не запишутся. Поэтому штатное завершение лучше применять, когда пользователь находится в режиме ожидания или навигации.
В некоторых случаях, особенно при работе через веб-сервер, разрыв может произойти не мгновенно из-за особенностей протокола HTTP и таймаутов пула приложений. Если сеанс не исчезает из списка сразу, не стоит паниковать и завершать процессы насильственно. Достаточно подождать несколько секунд, пока механизм очистки кластера не обновит статус соединения. Повторное нажатие кнопки завершения обычно не требуется.
Перед массовым отключением пользователей рекомендуется установить информационное сообщение в режиме предприятия, чтобы предупредить сотрудников о технических работах.
Использование режима исключительных работ для обновления
Когда требуется выполнить глобальные изменения, такие как обновление конфигурации или реструктуризация базы данных, простого отключения текущих пользователей недостаточно. Необходимо перевести информационную базу в режим, который запрещает начало новых сеансов и ожидает завершения старых. Этот механизм называется режимом исключительных работ и настраивается в свойствах информационной базы в консоли администрирования.
Для активации данного режима необходимо снять галочку с параметра «Разрешить начало сеансов» и, при необходимости, указать текст сообщения, которое будут видеть пользователи при попытке подключения. После применения настроек система перестанет пускать новых клиентов, а администратор сможет дождаться окончания работы оставшихся активных пользователей или завершить их вручную. Это гарантирует, что в момент обновления никто не будет вносить изменения в данные.
Следует помнить, что включение этого режима не разрывает существующие соединения автоматически. Администратору все равно придется мониторить список сеансов и завершать их по одному или группами. Только после того, как список активных сеансов (за исключением системных) станет пустым, можно приступать к конфигурированию или другим регламентным работам. Нарушение этого правила может привести к конфликтам версий метаданных.
☑️ Подготовка к исключительному режиму
Аварийное завершение через управление процессами ОС
В ситуациях, когда консоль администрирования не отвечает, сеанс завис в состоянии «неопределенности» или произошел сбой сетевого взаимодействия, приходится прибегать к более жестким методам. Завершение процессов на уровне операционной системы является крайней мерой, так как оно не дает платформе возможности корректно закрыть файлы данных и сбросить кэш. Использовать этот метод следует только тогда, когда штатные средства полностью исчерпаны.
На сервере 1С необходимо открыть диспетчер задач или использовать утилиту командной строки. Ключевыми процессами, которые потребляют ресурсы и держат соединения, являются rphost.exe (рабочий процесс) и rmngr.exe (менеджер кластера). Завершение процесса rphost.exe, соответствующего проблемному сеансу, приведет к мгновенному разрыву соединения. Однако это чревато тем, что СУБД может не успеть откатить незавершенную транзакцию.
Для более точного воздействия можно использовать утилиту ras (Remote Administration Server) из командной строки. Она позволяет управлять кластером без графического интерфейса. Команда для получения списка сеансов и их последующего удаления выглядит следующим образом:
ras cluster list
ras session kill --cluster=cluster_host --port=1545 --infobase=infobase_uuid --session=session_uuid
Использование утилиты ras предпочтительнее, чем «убийство» процессов в диспетчере задач, так как она взаимодействует с менеджером кластера более корректно. Тем не менее, риск повреждения данных при аварийном обрыве всегда остается. После такого вмешательства настоятельно рекомендуется выполнить тестирование и исправление базы данных средствами платформы.
⚠️ Внимание: Завершение процессов rphost через диспетчер задач может привести к тому, что в базе данных останутся «висящие» блокировки. Обязательно запускайте утилиту
chdbfl.exeили аналогичные средства проверки целостности СУБД после таких действий.
Особенности работы с файловыми и клиент-серверными базами
Методы завершения сеансов кардинально различаются в зависимости от типа подключения к информационной базе. В клиент-серверном варианте все соединения контролируются центральным менеджером кластера, что позволяет администратору видеть полную картину и управлять сессиями удаленно. В файловом варианте работа строится иначе: каждый пользователь подключается напрямую к файлам данных на диске, и централизованного управления нет.
Для файловой базы единственным способом увидеть активных пользователей является попытка открытия базы в режиме монопольного доступа или просмотр открытых файлов через средства операционной системы. Если файл 1Cv8.1CD заблокирован, значит, в базе кто-то работает. Завершить сеанс в этом случае можно только путем отключения пользователя от сетевого ресурса или завершения процесса 1cv8.exe на его рабочем месте.
Ниже приведена таблица, сравнивающая возможности управления сеансами для разных типов баз:
| Характеристика | Клиент-серверный вариант | Файловый вариант |
|---|---|---|
| Централизованное управление | Да (через консоль) | Нет |
| Видимость всех сеансов | Полная | Только при монопольном доступе |
| Безопасность завершения | Высокая | Низкая (риск повреждения файла) |
| Возможность блокировки входа | Да (настройки кластера) | Только правами ОС на папку |
При работе с файловыми базами в локальной сети критически важно следить за тем, чтобы пользователи корректно завершали работу. Принудительное отключение питания или разрыв сети у пользователя, работающего с файловой базой, с высокой вероятностью приведет к необходимости восстановления файла данных. Архитектура файлового варианта не обладает механизмами транзакционной защиты, сравнимыми с серверными СУБД.
Почему файловая база блокируется чаще?
В файловом варианте блокировка устанавливается на весь файл или крупные его части при интенсивной записи. Если один пользователь долго проводит документ, другие могут не иметь доступа к базе, пока операция не завершится.
Автоматизация контроля длительных сессий
В крупных компаниях ручной мониторинг сеансов становится неэффективным. Администраторы часто сталкиваются с проблемой, когда пользователи забывают закрыть программу, уходя на обед или домой, что приводит к исчерпанию лицензий. Для решения этой задачи целесообразно внедрять механизмы автоматического завершения неактивных сессий. Это можно реализовать как средствами самой платформы, так и через внешние скрипты.
В конфигурациях на базе 1С:Предприятие часто существует обработка «Администрирование» или аналогичные механизмы регламентных заданий, которые могут анализировать время последней активности пользователя. Если сеанс находится в режиме ожидания дольше установленного лимита (например, 30 минут), система может автоматически разорвать соединение. Настройка таких лимитов производится в параметрах системы или через расширения конфигурации.
Альтернативным подходом является использование внешних скриптов на языке PowerShell или BAT-файлов, которые периодически опрашивают консоль администрирования. Скрипт может выгружать список сеансов, анализировать время их начала и принудительно завершать те, что превышают допустимый порог. Такой подход требует осторожности, чтобы не отключить пользователей, которые действительно работают, но долго формируют сложный отчет.
⚠️ Внимание: Настройки автоматического отключения могут различаться в разных версиях платформы и конфигурациях. Всегда проверяйте документацию к вашей конкретной версии 1С:Предприятие перед внедрением автоматизации, так как интерфейсы и названия параметров могут меняться.
Автоматизация завершения сессий экономит лицензии и предотвращает накопление «мусорных» подключений, но требует тонкой настройки таймаутов, чтобы не мешать реальной работе.
Часто задаваемые вопросы (FAQ)
Что произойдет с данными, если я завершу сеанс во время проведения документа?
При штатном завершении через консоль платформа попытается откатить текущую транзакцию. Данные, которые еще не были зафиксированы в базе, будут потеряны для пользователя. Документ не проведется, и система вернется в состояние до начала операции. Однако, если использовалось аварийное завершение процессов, возможен риск частичной записи или повреждения таблиц блокировок.
Можно ли завершить сеанс конкретного пользователя, не зная его имени?
Да, в консоли администрирования можно ориентироваться не на имя пользователя, а на имя компьютера (Host) или время начала сеанса. Это полезно, когда пользователь не представился или работает под общим техническим аккаунтом. Идентификация по IP-адресу или имени узла сети позволяет точно найти нужное подключение в списке.
Почему после завершения сеанс все еще висит в списке?
Это может происходить из-за задержки обновления информации в консоли администрирования или потому, что процесс на сервере еще завершает фоновые операции (сброс буферов, закрытие соединений с СУБД). Обычно достаточно обновить список сеансов (клавиша F5) или подождать 10-20 секунд. Если сеанс не исчезает долго, возможно, процесс завис на уровне ОС.
Как завершить все сеансы сразу перед обновлением?
Самый надежный способ — включить режим «Запретить начало сеансов» в свойствах базы, дождаться ухода большинства пользователей, а затем выделить все оставшиеся сеансы в консоли (через Ctrl+A или Shift+Клик) и завершить их групповой операцией. Массовое завершение через контекстное меню работает быстрее, чем по одному.