Вызов команды RunScript в 1С, когда задание не помечено как запущенное

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

Чаще всего проблема проявляется в клиент-серверном режиме работы, где состояние заданий контролирует менеджер кластера (rmngr), а рабочие процессы (rphost) фактически выполняют код. Рассинхронизация между этими компонентами и есть основной источник ошибки. В файловом режиме подобная ситуация встречается реже и обычно связана с некорректной логикой запуска фоновых заданий из прикладного кода.

Что означает эта ошибка и где она возникает

RunScript — внутренняя команда планировщика заданий сервера 1С. Когда наступает время выполнения регламентного задания, менеджер кластера ставит задачу в очередь, назначает рабочий процесс и помечает задание как запущенное. Только после этого допустим вызов скрипта, содержащего код общего модуля, указанного в свойстве «Метод» задания.

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

Типичные причины рассинхронизации состояния задания

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

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

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

Диагностика: где искать источник проблемы

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

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

1. 1
   Откройте журнал регистрации и найдите ошибки по имени задания за нужный период
2. 2
   Проверьте в консоли кластера список сеансов: есть ли реальный сеанс у «выполняющегося» задания
3. 3
   Снимите зависшие фоновые задания через консоль или административные функции
4. 4
   Проверьте расписание задания на предмет слишком частого интервала
5. 5
   Проанализируйте код метода на исключения и длительные транзакции
6. 6
   При повторении ошибки перезапустите службу агента сервера 1С в нерабочее время

Исправление на уровне кода и расписания

Если задание запускается программно, используйте уникальные ключи фоновых заданий и проверяйте перед запуском, нет ли уже активного задания с тем же ключом. Это исключает конкуренцию двух экземпляров одного метода. Метод, вызываемый регламентным заданием, должен быть процедурой общего модуля с установленным признаком «Сервер» и, при необходимости, «Вызов сервера».

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

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

Процедура ВыполнитьОбработку() Экспорт
	Попытка
		// основная логика задания
	Исключение
		ЗаписьЖурналаРегистрации("Задание.Ошибка",
			УровеньЖурналаРегистрации.Ошибка,,,
			ОписаниеОшибки());
	КонецПопытки;
КонецПроцедуры

Исправление на уровне кластера и служб

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

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

Профилактика и контроль результата

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

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

Типичные ошибки администраторов

Отдельно отметим ситуацию, когда ошибку пытаются «заглушить», отключив задание совсем. Это маскирует проблему: бизнес-процесс, который обслуживало задание (обмен, расчёт, рассылка), перестаёт выполняться, и последствия проявляются позже и тяжелее.

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