Как снять фоновое задание на сервере 1С

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

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

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

Как понять, что фоновое задание зависло

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

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

Дополнительный признак — жалобы пользователей на блокировки: ошибки «Конфликт блокировок при выполнении транзакции» часто означают, что фоновое задание удерживает записи. В консоли кластера на вкладке «Блокировки» видно, какой сеанс является виновником.

Способ 1. Снятие задания через консоль кластера серверов

Консоль кластера (оснастка «Администрирование серверов 1С:Предприятия») — основной инструмент администратора. Она показывает все сеансы, включая сеансы фоновых заданий, и позволяет завершить их принудительно.

Откройте консоль, разверните нужный кластер, перейдите в ветку «Сеансы». В списке найдите сеанс с типом «Фоновое задание» — в колонке «Приложение» будет указано именно это. Чтобы найти нужный сеанс, сверьте имя информационной базы, время начала сеанса и, если возможно, имя метода задания в свойствах сеанса.

Выделите сеанс и нажмите «Удалить» (или выберите «Удалить» в контекстном меню). Сервер завершит сеанс, а фоновое задание перейдёт в состояние «Завершено аварийно». Если сеанс был связан с рабочим процессом, который завис, сам рабочий процесс продолжит работу — перезапускать его обычно не требуется.

1. 1
   Откройте оснастку «Администрирование серверов 1С:Предприятия»
2. 2
   Разверните кластер → нужная информационная база → Сеансы
3. 3
   Отсортируйте или отфильтруйте список по типу приложения «Фоновое задание»
4. 4
   Сверьте время начала и имя метода, чтобы не снять чужое задание
5. 5
   Выделите сеанс и нажмите «Удалить»
6. 6
   Проверьте в консоли заданий, что задание перешло в состояние «Завершено аварийно»

Если сеанс не удаляется

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

Способ 2. Снятие задания программно из встроенного языка

Встроенный язык 1С предоставляет менеджер фоновых заданий. Метод Отменить() отправляет заданию команду завершения. Этот способ удобен, если доступа к консоли кластера нет, но есть права администратора в базе и возможность выполнить код — например, через внешнюю обработку или консоль кода.

Задание = ФоновыеЗадания.НайтиПоУникальномуИдентификатору(Новый УникальныйИдентификатор(ИдЗадания));
Если Задание <> Неопределено Тогда
    Задание.Отменить();
КонецЕсли;

Найти нужное задание можно и без идентификатора — методом ФоновыеЗадания.ПолучитьФоновыеЗадания() с отбором по состоянию «Активно» и имени метода. Из результата выбирается нужный объект и для него вызывается Отменить().

Важно понимать ограничение: Отменить() не убивает поток мгновенно. Задание завершится, когда исполняющий его код достигнет точки, где платформа может безопасно прервать выполнение. Если задание висит на длинном запросе к СУБД, отмена может занять заметное время — тогда надёжнее снять сеанс через консоль кластера.

Способ 3. Стандартная консоль заданий и типовые средства

В конфигурациях на Библиотеке стандартных подсистем (БСП) есть штатная обработка «Регламентные и фоновые задания» (раздел «Администрирование» → «Обслуживание»). В ней на вкладке «Фоновые задания» виден список заданий с состояниями, и активное задание можно отменить кнопкой «Отменить выполнение».

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

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

Способ 4. Завершение на уровне СУБД

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

-- PostgreSQL: завершить зависшую сессию по PID
SELECT pg_terminate_backend(12345);

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

Проверка результата и последующие действия

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

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

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

Типичные ошибки при снятии фоновых заданий

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

Третья ошибка — игнорирование причины. Если задание зависло из-за взаимоблокировки или ошибки в коде, после перезапуска оно зависнет снова. Разберите журнал регистрации и технологический журнал, найдите причину и устраните её до повторного запуска.

Как предотвратить зависания в будущем

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

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

Для критичных заданий полезно настроить мониторинг: оповещение, если задание выполняется дольше заданного порога. Это позволяет реагировать до того, как зависшее задание начнёт мешать пользователям.

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