Почему не стартует регламентное задание Обработка произошедших бизнес-событий в 1С:Документооборот и как это исправить?

← На главную

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

Анализируем первичные признаки проблемы

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

Проверим статус задания в консоли регламентных заданий. Если оно активно, но дата последнего запуска «замерла» в прошлом — это первый сигнал системного сбоя.
Убедимся, что в свойствах информационной базы в консоли кластера 1С не установлена галочка Блокировка регламентных заданий.
Попробуем выполнить задание вручную. Если ручной запуск проходит успешно, значит, сам программный код задания (экспортная процедура в общем модуле) исправен, и проблема кроется в Менеджере заданий платформы.

Разбираемся в сетевых причинах: Ошибка 10054

Часто в инфраструктурных логах сервера можно обнаружить запись: An existing connection was forcibly closed by the remote host. Выясним причину этого явления. Эта ошибка (код 10054) означает, что сетевое соединение было разорвано одной из сторон в одностороннем порядке. В контексте 1С это может произойти между центральным сервером кластера и вспомогательным рабочим сервером, на который вынесено выполнение заданий.

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

Влияние временных зон и синхронизации времени

Посмотрим на еще один неочевидный аспект — синхронизацию системного времени. Если на сервере 1С время при старте службы отличается от реального (например, из-за настроек BIOS или часовых поясов), а затем операционная система синхронизирует его с контроллером домена, менеджер заданий 1С может «сбиться с толку». Если время «прыгнуло» назад, 1С будет ждать наступления момента следующего запуска по старому счетчику, который наступит еще не скоро.

Почему перезапуск службы 1С:Предприятия может не помочь?

Многие системные администраторы полагают, что рестарт службы 1C:Enterprise 8.3 Server Agent решает все проблемы. Однако это не всегда так. Разберем по шагам, что происходит:

При остановке службы процессы rphost и rmngr завершаются, но данные в кэше менеджера кластера (папка snccntx в каталоге srvinfo) могут сохранять информацию о состоянии сеансов.
Если в СУБД (MS SQL или PostgreSQL) остались незавершенные транзакции или блокировки на системных таблицах ScheduledJobs, после старта службы ситуация может повториться.
Сетевые сокеты на уровне ОС могут оставаться в состоянии TIME_WAIT, препятствуя нормальному переподключению менеджера заданий к рабочим процессам.

Алгоритм гарантированного решения проблемы

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

Шаг 1. Полная очистка серверного кэша и перезагрузка

Вместо простого перезапуска службы выполним перезагрузку всего физического (или виртуального) сервера, где запущен кластер 1С. Это позволит очистить:

Временные файлы операционной системы (папки Temp), к которым обращается 1С.
Зависшие сетевые соединения и дескрипторы файлов.
Оперативную память от фрагментированных кусков данных, которые могут блокировать создание новых потоков rphost.

Шаг 2. Проверка требований назначения функциональности

Рассмотрим настройки распределения нагрузки. Если в кластере используется несколько серверов, проверим, не запрещено ли выполнение фоновых заданий на конкретных узлах. Проанализируем настройки через Консоль администрирования кластера:


Настройки кластера -> Рабочие серверы -> Требования назначения функциональности.
Объект требования: Фоновые задания
Тип требования: Назначать (или Не назначать, если сервер выделен под другие нужды)

Шаг 3. Использование Технологического журнала для глубокой диагностики

Если перезагрузка не помогла, нам необходимо выяснить, что происходит в момент попытки старта задания. Настроим logcfg.xml для отслеживания событий старта фоновых заданий. Нам интересны события EXCP (исключения) и BackgroundJob.


<config xmlns="http://v8.1c.ru/7.4/config/log">
  <log location="C:\Logs\1C_Jobs" history="24">
    <event>
      <eq property="Name" value="BackgroundJob"/>
    </event>
    <event>
      <eq property="Name" value="EXCP"/>
    </event>
  </log>
</config>

Проанализируем полученные логи: если мы видим событие BackgroundJob.Start, но не видим BackgroundJob.Finish, значит задание аварийно завершается платформой (например, из-за нехватки памяти или ошибок доступа к файловой системе), не успевая записать ничего в Журнал регистрации. Для этой задачи подойдёт диагностика 1С и анализ технологического журнала.

Особенности задания в 1С:Документооборот

Помните, что задание ОбработкаПроизошедшихБизнесСобытий работает с регистром сведений ОчередьСобытий. Проанализируем содержимое этого регистра. Если в нем накопилось огромное количество записей (десятки тысяч) или есть «битые» ссылки на удаленные объекты (поможет инструмент выявления и удаления битых ссылок), регламентное задание может просто не успевать обрабатывать их в рамках одного сеанса или «вылетать» по таймауту. В таком случае поможет ручная очистка регистра или исправление ссылок через Тестирование и исправление.

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

← На главную