← На главную

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

Почему возникает данная ошибка

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

Шаг 1: Работа с консолью кластера серверов

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

1. Откройте «Консоль администрирования серверов 1С:Предприятия».
2. Перейдите в узел «Сеансы» нужной информационной базы.
3. Попытайтесь найти активный сеанс, который соответствует зависшему заданию. Часто это сеансы под системным пользователем, от имени которого выполняются регламентные задания.
4. Попробуйте принудительно удалить этот сеанс.
5. Если сеанс не удаляется, попробуйте найти связанный с ним «Рабочий процесс» (rphost) в дереве кластера и завершить его. Внимание: это приведет к разрыву соединений всех пользователей, работающих в данном рабочем процессе.

Шаг 2: Анализ соединений на уровне ОС

Если в консоли кластера действия не приносят результата, рассмотрим состояние процесса на уровне сервера Windows/Linux:

Иногда полезно сопоставить идентификатор процесса (PID) с тем, что мы видим в диспетчере задач. Вы можете найти процесс rphost.exe, который занимает подозрительно много ресурсов или висит в списке слишком долго. Однако помните, что перезагрузка процесса может быть болезненной для активных пользователей, поэтому этот метод стоит использовать только в крайнем случае. Для удаленного удаления зависших сеансов и завершения рабочих процессов можно использовать веб-приложение для управления сеансами и процессами сервера 1С.

Шаг 3: Полный перезапуск службы сервера 1С

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

Для перезапуска службы выполните следующие действия:

1. Зайдите в оснастку «Службы» (services.msc) на сервере.
2. Найдите службу «1C:Enterprise 8.3 Server Agent».
3. Нажмите «Остановить». Дождитесь полной остановки службы.
4. Нажмите «Запустить».

После этой операции список фоновых заданий будет переинициализирован, и база станет доступна для штатных операций, таких как выгрузка dt.

Как предотвратить повторение проблемы?

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

• Журнал регистрации: Изучите записи, сделанные непосредственно перед тем, как задание «зависло». Возможно, там присутствуют ошибки доступа к файлам или таймауты при обращении к базе данных.
• Блокировки SQL: Проверьте наличие блокировок на уровне MS SQL Server. Иногда длительные транзакции мешают регламентным заданиям завершить свою работу.
• Очистка кэша: Если проблема повторяется систематически для одних и тех же заданий, попробуйте очистить кэш сервера (папка srvinfo), предварительно остановив службу сервера.
• Оптимизация кода: Если зависание происходит на пользовательском регламентном задании, проверьте, нет ли там бесконечных циклов или тяжелых запросов, которые упираются в ограничение по времени исполнения.

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