В практике системного администрирования и разработки на платформе 1С часто возникает критическая ситуация: необходимо срочно обновить конфигурацию базы данных в клиент-серверном варианте, но активные фоновые задания блокируют этот процесс. Даже после удаления сеансов в консоли кластера, соединения могут оставаться активными, «воскресая» снова и снова. В этой статье мы подробно разберем механизмы работы фоновых заданий, выясним причины их «живучести» и рассмотрим пошаговые инструкции по их корректному завершению.
Проанализируем ситуацию, когда сеанс фонового задания удален, но соединение в списке консоли кластера остается. Основная причина кроется в различии между Сеансом и Соединением. Когда администратор удаляет сеанс через консоль MMC, менеджер кластера посылает сигнал рабочему процессу rphost на прерывание выполнения кода. Однако, если в этот момент фоновое задание выполняет тяжелую транзакцию на стороне СУБД (MS SQL Server или PostgreSQL), 1С ожидает ответа от сервера базы данных.
Рассмотрим подробнее: пока СУБД не завершит операцию или не произведет полный откат (Rollback) транзакции, физическое соединение будет считаться активным. Менеджер кластера 1С пытается поддерживать целостность и не всегда может «жестко» разорвать эту связь без риска повреждения данных. Именно поэтому мы часто видим ситуацию, когда после удаления соединения оно моментально появляется вновь — это механизм автоматического перезапуска регламентных заданий, если не была установлена блокировка.
Прежде чем приступать к «убийству» процессов, необходимо исключить их повторный запуск. Выполним следующие действия:
Важно понимать: если не включить блокировку регламентных заданий, планировщик будет пытаться запустить новое задание взамен того, которое вы только что принудительно завершили.
Иногда штатные средства консоли MMC работают некорректно. В таких случаях мы можем воспользоваться программным интерфейсом 1С. Разберем пример кода, который позволяет найти и отменить все активные фоновые задания для текущей базы:
МассивЗаданий = ФоновыеЗадания.ПолучитьФоновыеЗадания(Новый Структура("Состояние", СостояниеФоновогоЗадания.Активно));
Для Каждого Задание Из МассивЗаданий Цикл
Попытка
Задание.Отменить();
Сообщить("Задание " + Задание.ИмяМетода + " успешно отменено");
Исключение
Сообщить("Не удалось отменить задание: " + ОписаниеОшибки());
КонецПопытки;
КонецЦикла;
Стоит отметить, что метод Отменить() не гарантирует мгновенного прекращения работы. Он лишь устанавливает признак отмены. Чтобы код 1С внутри задания реагировал на этот сигнал, разработчикам рекомендуется в длительных циклах использовать метод КонтрольПрерыванияПользователя() или проверять свойство задания программно.
Если визуальная консоль зависает, профессионалы используют утилиту командной строки rac. Она позволяет более «жестко» управлять объектами кластера. Рассмотрим пример логики работы через rac:
Сначала получим список всех соединений базы, затем последовательно отправим команду на их завершение. Утилита rac напрямую взаимодействует с сервером ras, что часто помогает избежать проблем с кэшированием состояния в MMC-оснастке. Это особенно актуально для «фантомных» сеансов, которые не видны в обычном списке, но блокируют обновление.
Если соединение «зависло» в состоянии ожидания ответа от SQL-сервера, самым эффективным способом будет работа на уровне базы данных. Проанализируем ситуацию в MS SQL Server:
SPID:
SELECT session_id, host_name, program_name, status
FROM sys.dm_exec_sessions
WHERE context_info IS NOT NULL;
KILL [номер_SPID].Важный момент: после выполнения команды KILL СУБД начнет откат транзакции. Если транзакция была объемной (например, пересчет итогов), откат может занять значительное время. Пока СУБД не завершит откат, 1С будет продолжать видеть это соединение. Нужно просто дождаться завершения процесса в SQL.
Если ничего не помогло и конкретное фоное задание парализовало работу процесса, мы можем прибегнуть к завершению самого rphost. Посмотрим, как сделать это максимально аккуратно:
PID (идентификатор процесса) этого rphost.taskkill /PID [номер] /F завершим этот процесс.При этом остальные процессы rphost продолжат работу, и пользователи, распределенные по ним, не пострадают. Платформа 1С автоматически перезапустит завершенный процесс, но уже без «зависшего» задания (так как мы ранее включили блокировку регламентных заданий).
Подведем итог нашей совместной работы. Правильная последовательность действий при блокировке базы выглядит так:
Помните, что начиная с версии платформы 8.3.15, механизмы управления сеансами стали значительно стабильнее. Если вы часто сталкиваетесь с «фантомными» соединениями, рассмотрите возможность обновления платформы и оптимизации кода фоновых заданий, чтобы они не создавали избыточно длинных транзакций, которые невозможно быстро прервать.