В практике администрирования и разработки на платформе 1С:Предприятие 8.3 часто встречается ситуация, когда регламентное задание, настроенное на запуск один раз в день, начинает выполняться циклически с определенным интервалом (например, каждые 10 минут). При этом настройки в консоли заданий, такие как «Количество повторов при ошибке», игнорируются платформой. Рассмотрим подробно, почему это происходит и как устранить данное аномальное поведение.
Проанализируем базовый механизм работы планировщика заданий. Когда регламентное задание запускается, оно выполняется в рамках фонового задания, которое, в свою очередь, живет внутри рабочего процесса сервера rphost.exe. Здесь важно разделять два типа негативных исходов:
rphost.exe (например, нехватка памяти, ошибка обращения к памяти или сбой СУБД), планировщик заданий просто теряет связь с исполнителем. В консоли мы видим статус «Запуск», но событие «Завершение» или «Ошибка» не записывается.Выясним причину частого перезапуска: менеджер кластера 1С видит, что задание стартовало, но не предоставило отчет о завершении. С точки зрения кластера произошел технический сбой инфраструктуры, а не ошибка алгоритма. Поэтому планировщик пытается восстановить работу и запускает задание снова через внутренний системный интервал (по умолчанию это часто 10 минут), полагая, что в новом процессе задание сможет завершиться успешно. Настройки повторов при ошибке в данном случае игнорируются, так как платформа считает, что до анализа ошибки дело даже не дошло.
Рассмотрим ситуацию, когда в расписании не заданы параметры циклического повторения, но задание продолжает запускаться. В серверном режиме 1С существует защитный механизм. Если фоновое задание «исчезло» из списка активных без фиксации результата, оно ставится в очередь на перезапуск. Интервал в 10 минут является классическим для многих версий платформы как время ожидания перед повторной попыткой реанимации «упавшего» процесса. Проанализируем Журнал регистрации: если вы видите множество записей «Сеанс. Начало» без соответствующих записей «Сеанс. Завершение», это явный признак аварийного прерывания работы процесса.
Разберем одну из самых коварных причин — динамическое обновление конфигурации базы данных. Когда администратор обновляет конфигурацию «на лету», не выгоняя пользователей, кэш серверных процессов может рассинхронизироваться.
Планировщик заданий может хранить информацию о задании на основе старой структуры, в то время как исполняемый код требует новых метаданных. Это приводит к конфликтам в памяти процесса rphost.exe, его падению и бесконечному циклу перезапусков. Выясним, как это лечится: зачастую помогает только полная очистка серверного кэша и перезапуск службы ragent.
Если ваше задание продолжает запускаться слишком часто, выполним следующие шаги для диагностики и исправления:
Посмотрим на записи в Журнале регистрации с отбором по метаданным конкретного регламентного задания. Нас интересуют события:
Если записей о завершении или ошибке нет, а есть только запуски — подтверждается гипотеза об аварийном завершении процесса. Если же записи об ошибках есть, проверьте настройки самого задания в режиме «1С:Предприятие», так как настройки в Конфигураторе являются лишь значениями по умолчанию и могут быть переопределены пользователем с административными правами.
Проанализируем код внутри общего модуля, который вызывается заданием. Чтобы предотвратить падение процесса, рекомендуется оборачивать основной блок выполнения в конструкцию Попытка...Исключение. Это позволит платформе корректно обработать даже тяжелую ошибку и завершить задание со статусом «Ошибка», что задействует настройки количества повторов.
Рассмотрим пример правильной структуры процедуры регламентного задания:
Процедура ВыполнитьОбработкуДанных() Экспорт
Попытка
// Здесь располагается основной код задания
ПроводитьРасчетыИВыгрузку();
ЗаписатьРезультатВЛог("Задание завершено успешно");
Исключение
// Перехватываем ошибку, чтобы она не "уронила" сеанс
ТекстОшибки = ПодробноеПредставлениеОшибки(ИнформацияОбОшибке());
ЗаписьЖурналаРегистрации("РегламентноеЗадание.Сбой",
УровеньЖурналаРегистрации.Ошибка, , ,
"Произошла ошибка: " + ТекстОшибки);
// Вызываем исключение повторно, если хотим, чтобы сработал счетчик повторов 1С
// Или просто выходим, если хотим, чтобы задание считалось выполненным (с ошибкой в логе)
ВызватьИсключение "Критический сбой в регламентном задании";
КонецПопытки;
КонецПроцедуры
Иногда в системных таблицах базы данных происходит сбой, и в планировщике появляется «дубль» задания с тем же уникальным идентификатором. Рассмотрим метод «чистой переустановки»:
Выясним, не связано ли падение процесса с настройками кластера. Откроем консоль администрирования серверов 1С и проверим параметры рабочего сервера:
rphost.Если выполнение задания требует обработки огромных массивов данных, попробуйте оптимизировать код или увеличить эти лимиты, если ресурсы сервера позволяют.
Мы проанализировали ситуацию, когда регламентное задание в 1С запускается каждые 10 минут вопреки настройкам. Основная причина — нештатное завершение работы процесса, из-за которого планировщик не получает сигнал о завершении и уходит в цикл бесконечных попыток перезапуска. Для решения проблемы необходимо обеспечить стабильность кода через блоки Попытка, очистить кэш сервера и убедиться в отсутствии дублей в системных таблицах планировщика.