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

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

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

Завершение сеансов через интерфейс администратора

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

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

Однако этот метод имеет существенный недостаток: он работает только если клиентское приложение «живо» и способно обработать запрос сервера. Если программа зависла намертво или потеряна связь с сетью, кнопка завершения может не сработать, а статус пользователя останется активным еще долгое время.

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

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

💡

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

Управление сеансами в консоли кластера серверов

В клиент-серверном варианте работы (когда используется MS SQL, PostgreSQL или встроенный сервер ) основным инструментом администратора является консоль управления кластером серверов 1С:Предприятие (mmc). Этот инструмент позволяет управлять процессами на уровне службы ragent.

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

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

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

Сервер попытаться откатить транзакции, если они были открыты. Если процесс завис на уровне ядра ОС, может потребоваться более радикальное вмешательство.

📊 Как часто вам приходится "убивать" зависшие сеансы?
Ежедневно
Раз в неделю
Раз в месяц
Почти никогда

Мониторинг и завершение процессов на уровне ОС

Иногда программные методы бессильны, и администратору приходится спускаться на уровень операционной системы. Это актуально, когда процесс rphost.exe (рабочий процесс 1С) потребляет 100% процессорного времени или занимает всю оперативную память, блокируя работу всей базы.

В среде Windows для этих целей используется Диспетчер задач или более продвинутая утилита Process Explorer. Вам необходимо найти процесс rphost.exe, соответствующий проблемному сеансу. Ориентироваться можно по объему потребляемой памяти или идентификатору процесса (PID), который можно узнать из консоли кластера.

taskkill /F /PID 1234

Команда выше, выполненная в командной строке от имени администратора, принудительно завершит процесс с идентификатором 1234. Флаг /F означает Force (принудительно), что не дает процессу шанса на корректное завершение. Это «тяжелая артиллерия», которую следует использовать с осторожностью.

В Linux-среде аналогом служит утилита kill. Сначала находим PID процесса через ps -ef | grep rphost, а затем отправляем сигнал.SIGKILL. Важно понимать, что при таком завершении любые незафиксированные изменения в оперативной памяти процесса будут утеряны.

⚠️ Внимание: Убийство процесса rphost на уровне ОС может привести к рассинхронизации данных в таблице блокировок. После такой операции часто требуется запуск утилиты chdbfl (для файловых баз) или выполнение скрипта очистки таблиц блокировок (для SQL баз).

Использование сторонних мониторинговых систем, таких как Zabbix или Prometheus, позволяет автоматизировать этот процесс. Можно настроить скрипт, который будет автоматически перезапускать зависшие рабочие процессы при превышении пороговых значений потребления ресурсов.

Почему процесс rphost может зависнуть?

Чаще всего это связано с неоптимизированным кодом конфигурации, выполнением тяжелых запросов к базе данных без индексов или аппаратными проблемами сервера (нехватка RAM, ошибки диска).

Очистка таблиц блокировок и восстановление работоспособности

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

В файловых базах данных (.1CD) для решения этой проблемы используется специальная утилита chdbfl.exe, входящая в дистрибутив платформы. Она находится в каталоге установки программы. Запуск этой утилиты с ключом очистки позволяет удалить зависшие блокировки и восстановить целостность служебных таблиц.

Для клиент-серверных вариантов на основе MS SQL или PostgreSQL процедура сложнее. Необходимо выполнить SQL-запрос к системным таблицам базы данных 1С (обычно они имеют префикс _1CV8). Таблица _1CV8Locks хранит информацию о текущих блокировках.

Тип блокировки Таблица в SQL Риск очистки
Сеансовые блокировки _1CV8Sessions Низкий (можно чистить неактивные)
Блокировки данных _1CV8Locks Высокий (может нарушить транзакции)
Регистрация изменений _1CV8ChangeLog Средний (потеря истории изменений)

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

Современные версии платформы 1С (начиная с 8.3.10) обладают механизмами автоматической очистки «потерянных» блокировок при перезапуске сервиса кластера, но полагаться на них в критической ситуации не стоит. Ручная проверка остается надежнее.

💡

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

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

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

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

Также существует понятие Технологического перерыва. В этот период работа с базой полностью останавливается для всех, кроме пользователей с исключительными правами (обычно это администраторы). Настройка выполняется через консоль кластера или файл iblock.cfg в корневой папке базы.

  • 🛑 Полная блокировка — запрещает вход всем, включая администраторов (используется при критических сбоях).
  • 🔒 Блокировка для обычных пользователей — позволяет работать только роли «Администратор» или «Полные права».
  • Таймаут бездействия — настройка в консоли кластера, автоматически завершающая сеансы, где нет активности более N минут.

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

⚠️ Внимание: Параметры лицензирования (количество одновременных подключений) регулируются файлом hasp.key или настройками сервера лицензий. Искусственное ограничение сеансов не увеличивает количество доступных лицензий, а лишь управляет очередью доступа.

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

☑️ План действий при зависании базы

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

Автоматизация контроля сеансов через внешние скрипты

Для крупных предприятий, где количество пользователей исчисляется сотнями, ручное управление сеансами становится неэффективным. В таких случаях целесообразно использовать внешние скрипты на языке PowerShell или Python, которые взаимодействуют с COM-объектами администрирования 1С.

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

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

Также существуют готовые решения от партнеров 1С, такие как 1С:Администрирование сервера или различные мониторы производительности, которые предоставляют удобный веб-интерфейс для управления пользователями и анализа причин зависаний.

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

Можно ли выкинуть пользователя через ODBC?

Прямое завершение сеанса через ODBC-запрос невозможно, так как протокол взаимодействия клиента и сервера 1С проприетарный. Однако можно заблокировать запись в таблицы, что косвенно заставит сеанс завершиться с ошибкой.

Что делать, если кнопка "Завершить сеанс" не работает?

Если стандартные методы не помогают, значит процесс на уровне ОС завис «намертво». В этом случае необходимо использовать Диспетчер задач (Windows) или команду kill (Linux) для принудительного завершения процесса rphost.exe. После этого обязательно проверьте таблицы блокировок в базе данных.

Безопасно ли убивать процесс 1С через Диспетчер задач?

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

Как узнать, кто именно занял базу в файловом варианте?

В файловом варианте откройте базу в режиме Конфигуратора. В меню выберите "Администрирование" -> "Активные пользователи". Там будет виден список всех, кто сейчас подключен к файлу базы данных, и имя их компьютера.

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

Нет. Права на завершение чужих сеансов есть только у пользователей с полными правами или ролью "Администратор системы". Обычный пользователь может завершить только свой собственный сеанс.

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

При аварийном отключении питания сервер не успевает корректно закрыть соединения и очистить таблицы блокировок. Эти сеансы считаются "призрачными". Их необходимо удалить вручную через консоль кластера или утилиты очистки.