Отключаем пользователей от базы 1С: от мягкого выхода до принудительного

Пятница, 18:40. Нужно обновить конфигурацию , а в базе висят пять человек. Двое давно ушли домой и оставили 1С открытой, у третьего окно «не отвечает». Обновление не стартует: мешают активные сеансы.

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

Сначала выясните, кто в базе и какой у вас вариант

Способ зависит от того, как развёрнута база. Это видно сразу.

Перед любым отключением сделайте три вещи:

1. Узнайте, что делают люди. Закрытие сеанса посреди проведения документа оставит документ непроведённым, а закрытие во время длинной обработки прервёт её.
2. Предупредите всех: сообщением в чате, голосом, письмом. Назовите время, после которого сеансы будут закрыты.
3. Убедитесь, что есть свежая резервная копия. Если отключение нужно ради обновления или загрузки данных, копия обязательна в любом случае.

Штатные средства: активные пользователи и блокировка входа

Самый безопасный путь. Он не требует прав администратора кластера, достаточно администратора базы.

Список работающих пользователей

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

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

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

Рядом с активными пользователями находится форма блокировки работы пользователей. Для файловой базы это основной способ. Что в ней задаётся:

• ⏰ Период блокировки — с какого момента и до какого вход запрещён;
• 💬 Сообщение — текст, который увидит тот, кто попытается зайти;
• 🔑 Код разрешения — слово, с которым вы сами сможете войти, пока остальные заблокированы.

Код разрешения передаётся в параметре запуска: /UC МойКод. Строка запуска выглядит так:

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /S"сервер\база" /UCМойКод

Путь к программе зависит от установки, сверьтесь с ярлыком.

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

Консоль администрирования серверов: снимаем сеансы кластера

В клиент-серверном варианте основной инструмент — «Администрирование серверов 1С:Предприятия». Консоль входит в поставку платформы; на некоторых установках её нужно отметить отдельным компонентом.

Как найти сеансы

1. Запустите консоль и подключитесь к центральному серверу (по умолчанию он отзывается на порт 1540 для агента и 1541 для менеджера кластера).
2. Раскройте ветку Центральные серверы 1С:Предприятия → ваш сервер → Кластеры → нужный кластер.
3. Откройте Информационные базы и выберите базу.
4. Перейдите в раздел Сеансы.

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

Что сделать с сеансом

Выделите нужные строки и вызовите контекстное меню. Основное действие — удаление сеанса; консоль попросит подтверждение. После этого у пользователя клиент вернёт сообщение о разорванном соединении.

Так же отдельно показаны соединения (раздел Соединения). Если сеанс уже удалён, а соединение осталось, удалите и его.

Если консоль просит имя и пароль

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

Командная строка: утилита rac для скриптов и ночных задач

Когда сеансы нужно закрывать по расписанию, консоль не подходит. Утилита rac (Remote Administration Client) входит в поставку сервера и работает через службу ras.

Сначала убедитесь, что служба запущена. Для проверки на тестовой машине её можно поднять вручную:

ras cluster --port=1545

Дальше последовательность команд такая:

rac cluster list
rac session list --cluster=<идентификатор кластера>
rac infobase summary list --cluster=<идентификатор кластера>
rac session terminate --cluster=<идентификатор кластера> --session=<идентификатор сеанса>

Идентификаторы — длинные GUID. Первая команда выдаёт кластер, вторая — сеансы вместе с именем пользователя и информационной базой, третья — идентификаторы баз. Четвёртая закрывает конкретный сеанс.

Если в кластере заданы администраторы, добавляйте параметры авторизации (смотрите rac help). Точный набор параметров зависит от версии платформы, справка всегда актуальнее любой шпаргалки.

Мягкий вариант: сначала запретите новые входы

Блокировку, как и в штатных средствах, можно выставить и через rac. Команда rac infobase update принимает параметры запрета начала сеансов и запрета регламентных заданий (в справке rac help infobase update они называются --sessions-deny и --scheduled-jobs-deny), а также период, сообщение и код разрешения. После этого закрывайте оставшиеся сеансы командой terminate.

Блокировка новых подключений и регламентных заданий

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

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

В блокировке начала сеансов заполняют:

• ⏰ дату и время начала и конца;
• 💬 сообщение для тех, кто попробует войти;
• 🔑 код разрешения для вас;
• параметр блокировки — свободный текст, который доступен из кода конфигурации.

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

Когда сеанс не закрывается: операционная система и СУБД

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

Файловая база

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

1. Попросите пользователя завершить задачу 1cv8 в диспетчере задач (или 1cv8c для тонкого клиента ).
2. Если компьютер недоступен, а пользователя нет, посмотрите на файловом сервере, какие компьютеры держат открытыми файлы базы (оснастка «Общие папки» → «Открытые файлы»), и закройте их оттуда.
3. Файл блокировки 1Cv8.cdn руками не удаляйте, пока не убедились, что никто не работает : удаление при живом сеансе грозит порчей данных.

Клиент-серверная база

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

Порядок такой:

1. Удалите сеансы в консоли или через rac.
2. Если сеанс «завис» и не удаляется — удалите соединение.
3. Если не помогло, завершите конкретный rphost через диспетчер задач (в Linux — командой kill по номеру процесса). Кластер сам запустит новый процесс.
4. Остановку службы агента сервера оставляйте последним шагом.

Уровень СУБД

Иногда в кластере сеансов уже нет, а СУБД продолжает держать зависшее соединение с запросом. Для PostgreSQL это видно в представлении pg_stat_activity, а закрыть соединение можно функцией pg_terminate_backend(pid). В SQL Server аналог — команда KILL с номером сессии.

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

Почему сеансы зависают и как это предотвратить

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

• 🔧 Забытые окна. Человек ушёл с открытой базой. Настройте завершение неактивных сеансов по таймауту: в свойствах кластера и в параметрах рабочих серверов есть время простоя, после которого сеанс закрывается.
• 🐌 Тяжёлые отчёты. Один пользователь строит отчёт на всю базу за три года, остальные ждут. Смотрите в консоли в разделе сеансов, кто потребляет время и память.
• 📦 Незавершённые транзакции и блокировки. Долгое проведение документов, групповая обработка без разбиения на порции.
• 🧩 Сторонние подключения. Обмены, сайт, мобильные приложения, которые держат собственные сеансы и не закрывают их.
• 💾 Ресурсы сервера. Нехватка оперативной памяти или места на диске журналов, из-за чего процессы подвисают.

Для регулярных работ заведите порядок, который никто не нарушает:

1. Окно обслуживания объявлено заранее (например, воскресенье с 22:00).
2. За час включается блокировка начала сеансов с понятным сообщением.
3. За 10 минут уходит предупреждение людям, которые остались.
4. Затем закрываются оставшиеся сеансы и снимается блокировка по окончании.

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