Завершение сеансов в клиент-серверной 1С: от консоли до перезапуска агента

Чтобы выгнать пользователей из серверной базы 1С, откройте консоль администрирования кластера, разверните Информационные базы → <база> → Сеансы, выделите сеансы и выберите Удалить в контекстном меню. Но сеансы тут же появятся снова, если не закрыть вход: в свойствах базы включите «Блокировка начала сеансов включена», задайте сообщение и код разрешения. Сами вы потом зайдёте с ключом /UC<код>.

Способов отключить пользователей несколько, и выбирают их по ситуации. Консоль — когда есть доступ к серверу с Windows. Утилита rac — для скриптов, Linux и ночных регламентов. Блокировка из самой программы (форма «Блокировка работы пользователей») — когда хочется предупредить людей заранее. Перезапуск службы — последний довод, если сеансы «зависли» и не удаляются.

Какой способ выбрать: сравнение

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

Отключаем пользователей через консоль администрирования кластера

Консоль — оснастка MMC, ставится вместе с сервером 1С или отдельно компонентом «Администрирование сервера 1С:Предприятия». Если в меню «Пуск» её нет или она открывается пустой, зарегистрируйте библиотеку radmin.dll от имени администратора:

regsvr32 "C:\Program Files\1cv8\8.3.24.1342\bin\radmin.dll"

Номер версии в пути подставьте свой. Разрядность radmin.dll должна совпадать с разрядностью консоли MMC: для 64-битной Windows — библиотека из 64-битной платформы.

Пошагово

1. Откройте консоль, нажмите правой кнопкой на Central 1C:Enterprise 8.3 servers → Создать → Центральный сервер 1С:Предприятия 8.3.
2. Укажите имя сервера и порт агента — по умолчанию 1540.
3. Разверните Кластеры → <кластер> → Информационные базы → <нужная база>.
4. Если база запросит логин — введите учётку администратора базы (пользователь 1С с полными правами).
5. Откройте узел Сеансы. В колонках видно пользователя, компьютер, приложение и время начала.
6. Выделите сеансы (Shift или Ctrl), правая кнопка → Удалить.

💡 Колонка «Приложение» подсказывает, что за сеанс. «Тонкий клиент», «Веб-клиент», «Конфигуратор» — люди. «Фоновое задание» — регламенты. «COM-соединение» — внешние обработки и обмены. Удалять можно все, но фоновые запустятся заново, если их не заблокировать.

Почему пользователь возвращается

Удаление сеанса не мешает человеку снова запустить 1С. Через минуту он опять в списке. Поэтому, если база нужна вам надолго, сначала закройте вход.

1. В консоли правой кнопкой по базе → Свойства.
2. Отметьте «Блокировка начала сеансов включена».
3. Задайте «Начало» и «Конец» блокировки или оставьте пустыми — тогда блокировка бессрочная, до ручного снятия.
4. Заполните «Сообщение» — его увидит пользователь при попытке входа: «Идёт обновление, вход после 20:30».
5. Укажите «Код разрешения», например 7731.
6. Отметьте «Блокировка регламентных заданий включена», если работы требуют тишины в базе.
7. Нажмите ОК, затем удалите текущие сеансы.

Сами вы входите в заблокированную базу с ключом запуска /UC7731. Его можно дописать в поле «Дополнительные параметры запуска» в настройках базы в окне запуска или в ярлык.

Как отключить пользователей от базы 1С командной строкой: ras и rac

rac — консольный клиент администрирования. Сам он к агенту не ходит, ему нужен сервер администрирования ras. По умолчанию ras слушает порт 1545.

Запуск ras

Разово, из каталога bin платформы:

ras.exe cluster --port=1545 localhost:1540

Чтобы ras работал постоянно, его регистрируют службой Windows. На Linux в каталоге платформы есть готовые файлы для systemd; имена юнитов зависят от версии платформы, поэтому смотрите содержимое каталога установки.

Порядок команд

Сначала узнайте UUID кластера, затем UUID базы, затем список сеансов:

rac localhost:1545 cluster list
rac localhost:1545 infobase summary list --cluster=<UUID_кластера>
rac localhost:1545 session list --cluster=<UUID_кластера> --infobase=<UUID_базы>

Если на кластере заданы администраторы, к каждой команде добавьте --cluster-user=<логин> --cluster-pwd=<пароль>.

Удаление одного сеанса:

rac localhost:1545 session terminate --cluster=<UUID_кластера> --session=<UUID_сеанса>

Включение блокировки начала сеансов и регламентных заданий. Здесь нужен логин администратора самой базы:

rac localhost:1545 infobase update --cluster=<UUID_кластера> --infobase=<UUID_базы> ^
  --infobase-user=Администратор --infobase-pwd=<пароль> ^
  --sessions-deny=on --scheduled-jobs-deny=on ^
  --denied-message="Обновление базы, вход после 20:30" --permission-code=7731

Снятие блокировки — та же команда с --sessions-deny=off --scheduled-jobs-deny=off.

💡 Список параметров отличается между версиями платформы. Перед написанием скрипта выполните rac help session и rac help infobase на своём сервере — справка всегда соответствует установленной версии.

Для ночного регламента схема простая: включить блокировку → удалить все сеансы базы в цикле по выводу session list → выгрузка, обновление, тестирование → снять блокировку. Такой скрипт удобно повесить на планировщик заданий Windows или cron.

Блокировка работы и активные пользователи из самой программы

В типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) есть удобная форма «Блокировка работы пользователей». Найти её можно в разделе Администрирование → Обслуживание (в старых релизах раздел назывался «Поддержка и обслуживание»).

Чем она лучше консоли:

• ⏰ задаёте время начала, например через 15 минут;
• 📢 пользователи получают предупреждение и успевают записать документы;
• 🚪 в назначенное время программа сама завершает их сеансы;
• 🔑 код разрешения работает так же, через /UC.

Для серверной базы форма при установке блокировки спросит параметры администрирования кластера: логин и пароль администратора кластера, если он задан. Без них программа не сможет управлять сеансами на сервере.

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

Что умеет Конфигуратор

Конфигуратор покажет список: Администрирование → Активные пользователи. Но удалять чужие сеансы оттуда нельзя. Он полезен, чтобы понять, кто мешает.

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

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

Фоновые задания, внешние соединения и «хвосты» блокировок

Частая картина: людей уже нет, а монопольный режим не устанавливается. Мешают невидимые на первый взгляд сеансы.

• 🔄 Фоновые задания — обмены, загрузка курсов, полнотекстовый индекс. Включите «Блокировку регламентных заданий» и удалите их сеансы в консоли.
• 🔌 COM-соединения и HTTP-сервисы — интеграция с сайтом, внешние обработки, мобильные клиенты. Остановите источник или отключите публикацию на веб-сервере, иначе соединение вернётся.
• 👻 Сеанс без соединения — пользователь закрыл ноутбук, клиент «уснул». В консоли он виден, удаляется обычным способом.

Управляемые блокировки данных

У каждой базы в консоли есть узел Блокировки. Там видно, какой сеанс держит управляемую блокировку на данные. Эти блокировки живут в памяти кластера и исчезают вместе с сеансом. Отдельно «чистить таблицу блокировок» не нужно: удалите сеанс-владелец, и блокировка снимется.

Если блокировка не снимается после удаления сеанса, проверьте вкладку Рабочие процессы: возможно, процесс rphost, обслуживавший сеанс, завис на долгом запросе к СУБД. Такой запрос может держать и блокировки на стороне SQL Server или PostgreSQL.

Крайние меры: перезапуск службы агента и очистка кэша сервера

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

Windows

Служба называется «Агент сервера 1С:Предприятия 8.3» с указанием разрядности. Перезапуск через services.msc или командой — имя службы посмотрите в её свойствах:

net stop "<имя службы агента>"
net start "<имя службы агента>"

Если служба не останавливается за пару минут, в диспетчере задач завершите процессы ragent, rmngr, rphost. Это жёстко: незавершённые транзакции откатит СУБД, но данные, не записанные в базу, пропадут.

Linux

На свежих платформах сервер ставится как systemd-служба, перезапуск — systemctl restart <имя юнита>. На старых установках — init-скрипт srv1cv83. Точное имя смотрите командой systemctl list-units | grep 1C или grep srv1cv8.

Очистка сеансовых данных

Если после перезапуска сеансы «воскресают» или сервер ведёт себя странно, чистят кэш кластера.

1. Остановите службу агента.
2. Откройте каталог кластера — по умолчанию srvinfo\reg_1541 в каталоге данных сервера.
3. Перенесите в резервную папку подкаталоги snccntx* внутри каталогов баз.
4. Запустите службу.

Профилактика: чтобы выгонять пользователей приходилось реже

Большинство «зависших» сеансов — это люди, ушедшие домой с открытой 1С. Это лечится настройками кластера.

В свойствах кластера (правая кнопка по кластеру → Свойства) есть два параметра:

Там же настраивают перезапуск рабочих процессов: «Интервал перезапуска» и «Принудительно завершать проблемные процессы». Регулярный перезапуск rphost раз в сутки ночью снимает часть проблем с памятью и долгими сеансами.

Ещё несколько привычек:

• 📅 Обновления и выгрузки — по расписанию, которое знают все. Тогда блокировка не будет сюрпризом.
• 🧾 Сообщение блокировки — с временем окончания и контактом. Меньше звонков.
• 🔐 Задайте администратора кластера. Без него консолью и rac может управлять любой, кто достучится до порта.
• 🗂️ Держите скрипт отключения пользователей готовым и проверенным на тестовой базе.

Частые вопросы