Зависла задача в 1С: как завершить сеанс и фоновое задание

Если операция в 1С висит и не отвечает, в клиент-серверной базе её снимают завершением сеанса: в консоли администрирования серверов откройте кластер, ветку Сеансы, найдите нужную строку по имени пользователя и удалите её. В файловой базе отдельного сеанса на сервере нет — там закрывают зависший процесс 1cv8.exe и чистят кэш клиента.

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

Ниже — диагностика и все рабочие способы: от штатных средств режима предприятия и конфигуратора до консоли кластера, утилиты rac и крайней меры на уровне СУБД.

Что именно зависло: сеанс, фоновое или регламентное задание

Сначала определите тип «задачи» — от этого зависит, где её искать и как снимать.

• 🧑‍💻 Сеанс пользователя — конкретное подключение человека к базе. Завис клиент, не реагирует форма, крутится «часики».
• ⚙️ Фоновое задание — операция, которую система выполняет асинхронно: длинный отчёт, групповое перепроведение, обмен данными. Работает в отдельном сеансе от имени служебного пользователя.
• ⏰ Регламентное задание — фоновое задание по расписанию: загрузка курсов валют, обмен с сайтом, закрытие месяца по графику. Если оно «встало», обычно висит именно его фоновый сеанс.

Второй важный вопрос — тип базы:

Как найти активные сеансы и зависшие задания

В режиме 1С:Предприятие список подключений смотрят через стандартную форму «Активные пользователи». В интерфейсе «Такси» включите команду «Все функции»: значок Сервис и настройки (шестерёнка справа вверху) → Настройки → Параметры → галочка «Отображать команду “Все функции”». После этого: главное меню → Все функции → Стандартные → Активные пользователи.

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

Регламентные задания в типовых конфигурациях (БП 3.0, ЗУП 3.1, УТ 11) смотрят отдельно: раздел Администрирование → группа Обслуживание → Регламентные и фоновые задания. Там видно, какое задание запущено, когда стартовало и чем закончилось прошлый раз. Если задание «выполняется» подозрительно долго — это кандидат на завершение.

Понять, чем именно был занят сеанс перед зависанием, помогает журнал регистрации: раздел Администрирование → Обслуживание → Журнал регистрации. Отфильтруйте записи по нужному пользователю и времени — так вы увидите последнюю операцию (проведение документа, формирование отчёта, обмен) и поймёте, можно ли её прервать без потерь. Этот же журнал позже покажет, не повторяется ли сбой.

Для клиент-серверной базы полную картину даёт консоль администрирования серверов или утилита rac:

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

Команда выведет список сеансов с их идентификаторами, именами пользователей и временем старта. Идентификатор кластера узнаётся через rac cluster list. Полный перечень подкоманд — в rac help session.

Завершение сеанса через режим предприятия и конфигуратор

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

1. Откройте Администрирование → Обслуживание → Регламентные и фоновые задания.
2. Перейдите на вкладку фоновых заданий, найдите «выполняется» с нужным именем.
3. Выделите строку и нажмите команду отмены в командной панели списка (значок остановки / «Отменить»).
4. Если зависло регламентное задание — на вкладке регламентных снимите у него флаг «Включено», чтобы оно не перезапустилось, пока вы разбираетесь.

Конфигуратор напрямую сеансы не завершает даже в клиент-серверной базе — его форма Администрирование → Активные пользователи показывает список, но кнопки «снять» там нет. Зато конфигуратор умеет заблокировать новые подключения: меню Администрирование → Блокировка установки соединений с информационной базой. Это полезно, когда нужно дождаться, пока текущие сеансы завершатся сами, и никого нового не пускать.

Сброс сеанса в консоли администрирования серверов и через rac

Для клиент-серверной базы это основной инструмент. Снимаем конкретный сеанс, не трогая остальные.

Через консоль (оснастку MMC «Администрирование серверов 1С Предприятия»):

1. Разверните Central 1C:Enterprise ... servers → ваш центральный сервер → кластер.
2. Откройте ветку Сеансы. В списке — все подключения с именами пользователей и приложением (толстый клиент, веб-клиент, фоновое задание).
3. Найдите зависший по имени пользователя и времени начала.
4. Правый клик по строке → Удалить. Сеанс снимается принудительно.
5. Если после этого в базе осталось «висячее» соединение — проверьте ветку Соединения и удалите его там же.

Через утилиту rac (удобно на сервере без графики):

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

Идентификатор сеанса берётся из rac session list (поле session). После снятия повторите rac session list и убедитесь, что строки больше нет.

Остановка службы кластера (1C:Enterprise 8.x Server Agent) тоже снимет все сеансы, но это грубый способ: оборвутся все пользователи базы. Прибегайте к нему, только когда снять конкретный сеанс не удаётся и база всё равно недоступна для работы.

Крайняя мера: снятие на уровне СУБД

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

PostgreSQL — найдите «зависшее» соединение и завершите его:

SELECT pid, usename, state, query_start, state_change
FROM pg_stat_activity
WHERE datname = 'имя_базы'
ORDER BY query_start;

SELECT pg_terminate_backend(<pid>);

Microsoft SQL Server — определите SPID и снимите его:

EXEC sp_who2;
-- найдите SPID, относящийся к нужной базе
KILL <spid>;

Сложность в том, что одно подключение СУБД не равно одному сеансу 1С: платформа держит пул соединений, и сопоставить «тот самый» сеанс с конкретным pid/spid непросто. Поэтому СУБД-способ применяют, когда база фактически встала целиком, а не для аккуратного снятия одного пользователя. После него обязательно откройте консоль кластера и проверьте, не осталось ли «мёртвых» сеансов и соединений — их тоже удалите.

Блокировки и кэш: что чистить, а что уйдёт само

Частый вопрос: нужно ли после зависания вручную «чистить таблицу блокировок». Нет. Управляемые блокировки 1С живут в менеджере блокировок кластера, в оперативной памяти, а не в постоянной таблице базы. Как только сеанс завершён — его блокировки снимаются автоматически. Отдельно «чистить» их не требуется и такого штатного инструмента нет.

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

• 📁 Удалить папку кэша. Закройте все клиенты 1С. Удалите каталог базы внутри %LOCALAPPDATA%\1C\1cv8\ (у каждой информационной базы — своя подпапка со служебным именем). При следующем запуске кэш пересоздастся.
• 🚀 Параметр запуска /ClearCache. Добавьте его к строке запуска клиента, чтобы очистить локальный кэш при старте.

Для файловой базы отдельного серверного сеанса нет. Если клиент завис намертво:

1. Через диспетчер задач Windows завершите процесс 1cv8.exe зависшего пользователя.
2. Убедитесь, что в папке базы не остался файл блокировки от аварийно закрытого клиента, — после завершения всех процессов он освободится сам.
3. Почистите кэш, как описано выше.

Профилактика: расписание заданий и таймауты сеансов

Чтобы задачи зависали реже, настройте фон и сеансы заранее.

• ⏰ Разнесите регламентные задания по времени. В Администрирование → Обслуживание → Регламентные и фоновые задания задайте тяжёлым заданиям (обмены, пересчёты) расписание на ночь или обеденное окно, а не на пик рабочего дня.
• 🧮 Ограничьте одновременность. Если несколько тяжёлых заданий стартуют в одну минуту, они конкурируют за блокировки. Сдвиньте расписания на разные интервалы.
• 🔕 Отключайте ненужное. Лишние включённые регламентные задания (обмен с давно отключённым сайтом, устаревшая синхронизация) — источник «вечно выполняющихся» фонов. Снимите флаг «Включено».
• 🕒 Задайте таймаут сеанса. В типовых конфигурациях в настройках пользователей и прав есть ограничение времени неактивного сеанса — брошенные открытыми клиенты будут завершаться сами и не копить блокировки.
• 📊 Следите за ресурсами сервера. Большинство «массовых» зависаний — это не единичная задача, а нехватка оперативной памяти или диска под СУБД. Настройте в свойствах рабочего сервера предельный объём памяти рабочих процессов, чтобы перегруженный процесс перезапускался, а не тянул всю базу за собой.
• 💾 Делайте регулярные резервные копии. Тогда крайние меры (СУБД, остановка службы) перестают быть страшными: есть куда откатиться.

Чек-лист быстрого реагирования, когда задача уже зависла:

Если зависает регулярно одна и та же операция — это уже не «снять и забыть», а повод разобраться с причиной:

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