Как найти и остановить зависшее фоновое задание, которое мешает обновить конфигурацию 1С?

← На главную

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

Шаг 1. Анализ активных сеансов через консоль администрирования

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

Проанализируем список сеансов, учитывая возможные ограничения на количество подключений. Даже если в колонке Пользователь пусто или указан системный пользователь, обратим внимание на колонку Приложение. Фоновые задания помечаются как BackgroundJob. Если мы видим такой сеанс, который висит длительное время (включая спящие сеансы 1С), это и есть наш кандидат на завершение. Однако, просто удалить сеанс часто бывает недостаточно — механизм кластера может мгновенно запустить его снова.

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

Шаг 2. Идентификация задания через Журнал регистрации

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

В консоли администрирования найдем номер сеанса (колонка Номер сеанса) подозрительного фонового задания.
Откроем Журнал регистрации в режиме 1С:Предприятие.
Установим фильтр по номеру сеанса, который мы выписали ранее.

В ЖР мы увидим событие Фоновое задание. Запуск, в деталях которого будет указано наименование регламентного задания или метаданные метода, который был вызван. Это позволит нам выяснить причину «зависания» (например, бесконечный цикл в обработке данных или ожидание ответа от внешнего веб-сервиса).

Шаг 3. Глубокий анализ показателей производительности в консоли

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

Захвачено СУБД: Если это значение постоянно растет или замерло на большой величине, значит, фоновое задание выполняет тяжелый SQL-запрос. В этом случае проблему нужно решать на уровне оптимизации запроса.
Время вызова (текущее): Если счетчик времени идет, но обращения к СУБД нет, скорее всего, код 1С «зациклился» в какой-то итерации или ожидает внешнее событие (чтение файла, ответ API).

Шаг 4. Использование инструментов СУБД (MS SQL Server / PostgreSQL)

Иногда сеанс в 1С уже кажется завершенным, но на уровне базы данных транзакция все еще активна. Это так называемые «фантомные сеансы». Проанализируем ситуацию через SQL Server Management Studio (SSMS). Мы можем выполнить следующий запрос, чтобы увидеть активные процессы:

<code>
EXEC sp_who2;
-- Или более современный вариант для анализа блокировок:
SELECT * FROM sys.dm_exec_requests WHERE session_id > 50;
</code>

Если мы видим процесс, инициированный пользователем, под которым работает сервер 1С, и он блокирует таблицы конфигурации (ConfirmConfig, Config), мы можем принудительно завершить его командой KILL [номер_сессии]. Однако делать это следует крайне осторожно и только в случае, если штатное завершение через консоль 1С не помогло.

Шаг 5. Проверка «Очереди заданий» в конфигурациях на БСП

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

Рассмотрим порядок действий:

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

Шаг 6. Настройка технологического журнала для выявления причин

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

<code>
<config xmlns="http://v8.1c.ru/7.4/get/logcfg">
  <log location="C:\LOGS\BackgroundErrors" history="24">
    <event>
      <eq property="Name" value="EXCP"/>
    </event>
    <event>
      <eq property="Name" value="DBMSSQL"/>
      <gt property="Duration" value="100000"/>
    </event>
    <property name="All"/>
  </log>
</config>
</code>

Проанализируем полученные логи. Событие EXCP покажет нам все исключительные ситуации, а DBMSSQL с длительностью более 0.1 секунды (100 000 микросекунд) позволит выявить проблемные запросы к базе данных.

Шаг 7. Радикальные методы: Очистка серверного кеша и перезапуск службы

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

Остановим службу Агент сервера 1С:Предприятия.
Перейдем в каталог srvinfo (путь по умолчанию: C:\Program Files\1cv8\srvinfo).
Найдем папку с идентификатором вашей базы и внутри неё очистим папку snccntx (кеш сеансовых данных). Внимание: не удаляйте файлы базы данных и критичные настройки кластера!
Запустим службу заново.

Этот метод гарантированно очищает все «призрачные» фоновые процессы, которые могли мешать монопольному доступу.

Резюме и рекомендации

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