Зависла операция в 1С 8.3: от Ctrl+Break до завершения сеанса на сервере

Прервать операцию в 1С 8.3 сначала пробуют сочетанием Ctrl+Break или кнопкой отмены в окне ожидания. Не помогло — завершают сеанс пользователя: в файловой базе через закрытие процесса клиента, в клиент-серверной через консоль администрирования кластера. Крайний способ — остановить запрос на стороне СУБД или перезапустить рабочий процесс.

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

Как прервать операцию в 1С из интерфейса пользователя

Начните с клавиатуры. В тонком и толстом клиенте Ctrl+Break посылает сигнал прерывания. Платформа спросит, прервать ли выполнение, и после согласия откатит незавершённую транзакцию.

Сигнал срабатывает не всегда. Код на клиенте проверяет прерывание только там, где разработчик вызвал ОбработкаПрерыванияПользователя(). Если цикл написан без этой проверки, нажатие ничего не даст до конца цикла.

Что ещё можно сделать без администратора:

1. 🟡 Если на экране окно длительной операции с индикатором — нажмите в нём кнопку отмены. В типовых конфигурациях на БСП отчёты и тяжёлые обработки идут в фоне, и отмена в окне снимает это фоновое задание.
2. 🟡 Если отчёт формируется в своей форме — закройте форму отчёта. Для фонового формирования БСП это тоже отменяет задание.
3. 🟡 Подождите 1–2 минуты. Проведение крупного документа, закрытие месяца или загрузка выписки на тысячи строк могут идти долго, и это нормально. Признак зависания — нет нагрузки на процессор у процесса 1С и нет движения индикатора.
4. 🔴 Если окно пишет «Не отвечает» — переходите к завершению сеанса (раздел ниже).

Файловая база: снять процесс клиента

В файловом варианте весь код выполняется в процессе клиента. Остановить операцию — значит закрыть этот процесс.

1. Откройте Диспетчер задач (Ctrl+Shift+Esc), вкладка «Подробности».
2. Найдите процесс клиента: 1cv8c.exe — тонкий клиент, 1cv8.exe — толстый клиент и Конфигуратор.
3. Если открыто несколько баз, ориентируйтесь по загрузке ЦП и памяти: зависший процесс обычно грузит одно ядро на 100%.
4. Нажмите «Снять задачу».

Транзакция в файловой базе при обрыве откатывается. Документ, который проводился в момент снятия, останется непроведённым, а не «наполовину проведённым».

Завершение сеанса в консоли администрирования кластера

В клиент-серверной базе тяжёлый код выполняется на сервере в рабочем процессе rphost. Закрыв клиента, вы не всегда останавливаете серверный вызов: он может доработать до конца и держать блокировки. Правильный путь — завершить сеанс на сервере.

Порядок в консоли администрирования серверов 1С:

1. Запустите «Администрирование серверов 1С Предприятия». Если оснастка не открывается или пишет об ошибке класса, перерегистрируйте radmin.dll той версии платформы, что стоит на сервере: regsvr32 "C:\Program Files\1cv8\8.3.xx.xxxx\bin\radmin.dll" из командной строки администратора.
2. Раскройте сервер → Кластеры → ваш кластер → Информационные базы → нужная база → Сеансы.
3. Найдите сеанс по колонкам «Пользователь», «Компьютер», «Приложение» и «Начало работы». Полезны колонки с длительностью текущего вызова и объёмом захваченной памяти: у зависшего сеанса они растут.
4. Откройте узел Блокировки той же базы. Там видно, какой сеанс держит управляемые блокировки, которых ждут остальные.
5. Правой кнопкой по сеансу → Удалить. Подтвердите.

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

То же из командной строки через rac

На Linux-сервере или для скриптов используют утилиту rac. Ей нужен запущенный сервис ras (по умолчанию порт 1545).

rem список кластеров — берём cluster UUID
rac cluster list

rem сеансы кластера: ищем нужный по user-name и host
rac session list --cluster=<cluster-uuid>

rem завершить сеанс
rac session terminate --cluster=<cluster-uuid> --session=<session-uuid>

Если на кластере заведён администратор, добавьте --cluster-user= и --cluster-pwd=. Набор параметров для своей версии платформы проверьте через rac help session.

Завершение сеансов из самой конфигурации

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

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

Остановка фоновых и регламентных заданий

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

Где их искать в типовой конфигурации: Администрирование → Обслуживание → Регламентные операции → Регламентные и фоновые задания. В старых релизах раздел назывался «Поддержка и обслуживание».

Что делать в этой форме:

1. 🔎 На вкладке фоновых заданий найдите задание в состоянии «Активно» с давним временем начала.
2. ⛔ Выделите его и выполните команду отмены. Задание получит сигнал и остановится на ближайшей точке, где код это проверяет.
3. 🔧 Если зависает регламентное задание по расписанию — откройте его карточку на соседней вкладке, снимите флажок «Включено» на время разбора.

Если форма не помогает, фоновое задание видно в консоли кластера как отдельный сеанс с приложением «Фоновое задание». Его завершают так же, как сеанс пользователя: Удалить.

Запрет регламентных заданий на уровне кластера

На время обновления или разбора проблем удобно отключить все регламентные задания базы разом:

• В консоли кластера → свойства информационной базы → флажок Блокировка регламентных заданий включена.
• Там же Блокировка начала сеансов включена — новые пользователи не войдут. Сообщение и код разрешения задаются в соседних полях.
• Чтобы самому войти при включённой блокировке, укажите код разрешения в параметре запуска /UC<код>.

Остановка запроса на стороне СУБД

Бывает так: сеанс в консоли 1С уже удалён, а запрос к базе продолжает работать и держит блокировки на таблицах. Или СУБД откатывает огромную транзакцию, и база стоит. Тогда смотрят прямо в SQL Server или PostgreSQL.

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

Microsoft SQL Server

Посмотреть активные запросы и цепочку блокировок:

SELECT r.session_id, r.blocking_session_id, r.status,
       r.wait_type, r.wait_time, r.total_elapsed_time,
       DB_NAME(r.database_id) AS db, s.host_name, s.program_name
FROM sys.dm_exec_requests r
JOIN sys.dm_exec_sessions s ON s.session_id = r.session_id
WHERE s.is_user_process = 1
ORDER BY r.total_elapsed_time DESC;

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

KILL 87;               -- 87 — номер сессии из запроса выше
KILL 87 WITH STATUSONLY;  -- прогресс отката

Откат длинной транзакции идёт примерно столько же, сколько она успела поработать. Повторный KILL его не ускорит, а перезапуск службы SQL Server только перенесёт откат на этап запуска базы.

PostgreSQL

SELECT pid, usename, client_addr, state,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       left(query, 100) AS query
FROM pg_stat_activity
WHERE datname = 'имя_базы'
ORDER BY xact_start;

Блокирующих подскажет pg_blocking_pids(pid). Останавливают в два шага:

SELECT pg_cancel_backend(12345);     -- мягко: отменить текущий запрос
SELECT pg_terminate_backend(12345);  -- жёстко: закрыть соединение

Сначала pg_cancel_backend. Он прерывает запрос, но оставляет соединение. pg_terminate_backend нужен, если отмена не сработала за минуту-две.

Перезапуск рабочего процесса и службы сервера

Если не реагирует сам rphost — консоль показывает сеансы, но удалить их не получается, память процесса растёт — остаётся перезапуск.

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

Варианты по нарастанию:

Каталог srvinfo и файлы с описанием кластера (1CV8Clst.lst и соседние) не удаляйте целиком. В них хранится регистрация баз в кластере, и после удаления базы придётся регистрировать заново.

Почему операции в 1С зависают и как это предотвратить

Найти причину важнее, чем каждый раз снимать сеанс. Типичные сценарии:

• 🔒 Ожидание блокировки. Два пользователя проводят документы по одним остаткам. Через 20 секунд ожидания управляемой блокировки платформа выдаёт Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки. Если такое повторяется — смотрите, кто держит длинную транзакцию.
• 🧱 Длинная транзакция. Обработка проводит 5 000 документов в одной транзакции. Пока она идёт, остальные ждут. Перепроведение и групповые операции лучше запускать вне рабочего времени.
• 🌐 Ожидание внешнего ресурса. HTTP-запрос к сайту или банку без таймаута, недоступный сетевой диск, COM-соединение. Процесс не грузит ЦП, а просто ждёт.
• 💾 Нехватка ресурсов. Закончилось место на диске, переполнен tempdb в SQL Server, rphost упёрся в память.
• 🔁 Ошибка в доработке. Бесконечный цикл во внешней обработке или расширении. Выдаёт себя постоянной загрузкой одного ядра на 100%.

Что настроить, чтобы зависаний было меньше и их было видно:

1. Ограничения памяти кластера. В свойствах кластера задайте «Допустимый объём памяти рабочих процессов», «Интервал превышения допустимого объёма памяти» и «Безопасный расход памяти за один вызов». Тогда кластер сам перезапустит раздутый процесс или оборвёт тяжёлый вызов, а не уронит весь сервер.
2. Технологический журнал. Файл logcfg.xml в каталоге conf платформы. События TLOCK, TTIMEOUT, TDEADLOCK показывают конфликты блокировок, событие CALL — долгие серверные вызовы. Включайте на время разбора: журнал быстро растёт.
3. Журнал регистрации. Администрирование → Обслуживание → Журнал регистрации, отбор по пользователю и времени зависания. Видно, какая операция была последней перед обрывом.
4. Расписание. Регламенты, обмены и пересчёты итогов — в нерабочие часы, а не каждые 5 минут днём.
5. Таймауты в доработках. Для HTTP-соединений задавайте таймаут при создании соединения, в длинных клиентских циклах вызывайте ОбработкаПрерыванияПользователя().

Что проверить после принудительной остановки

Обрыв операции сам по себе базу не портит: незавершённая транзакция откатывается. Но последствия бывают, и их стоит проверить.

1. Документ, который проводился. Откройте его. Если он не проведён — проведите заново. Если это было групповое перепроведение, запустите его снова с того места, где оборвалось: часть документов уже проведена.
2. Обмен данными. Прерванный обмен с УТ, сайтом или банком повторите вручную. Сообщения, которые не успели загрузиться, придут в следующем сеансе.
3. Кэш клиента. Если после обрыва база открывается с ошибками формы или старыми данными, запустите клиент с параметром /ClearCache или удалите базу из списка и добавьте снова.
4. Признаки повреждения. Ошибки чтения, «нарушение целостности», падение при открытии — только тогда нужно тестирование. Для файловой базы есть утилита chdbfl.exe в каталоге bin платформы, для любой базы — Администрирование → Тестирование и исправление в Конфигураторе. Обе требуют монопольного доступа, все пользователи должны выйти.
5. Флажки блокировок. Если включали блокировку сеансов или регламентных заданий — снимите её.

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