COMConnection: ноль сеансов в консоли не снимает эксклюзивный режим

На шаге «Установка монопольного режима» мастер «Обновление конфигурации базы данных» крутит индикатор уже восемь минут, а в консоли кластера 1С:Предприятие 8.3 в списке сеансов информационной базы «СервисЗапчасти» (1С:Комплексная автоматизация 2.5, клиент‑сервер, SQL Server) пусто.

Хронология

• 20:02 — согласовали окно: остановить обмен РИБ, уведомить склад и сервис, отключить регламентное задание «СинхронизацияОстатковWMS» на время cf.

• 20:11 — администратор запустил конфигуратор от имени доменной учётки, принял cf из хранилища, открыл «Обновление конфигурации базы данных».

• 20:14 — мастер прошёл проверку прав и реструктуризации на тестовой копии; на продуктиве шаг «Завершение работы пользователей» показал «Активных сеансов: 0».

• 20:16 — индикатор завис на «Установка монопольного режима»; повторное обновление списка сеансов в консоли кластера по‑прежнему 0 строк в представлении «Сеансы».

• 20:19 — в технологическом журнале на rphost появились записи EXCP с текстом про невозможность установить монопольный режим; длинных запросов к SQL Server в том же интервале не зафиксировали.

• 20:22 — версия про «зависший» регламентное задание «ПересчётСебестоимостиПартий» не сработала: в журнале регистрации фоновые задания завершились в 19:47, блокировок регистра «СебестоимостьТоваров» не было.

• 20:24 — гипотеза про кладовщика Sklad04 с открытым документом «ЗаказКлиента» тоже отпала: последняя запись пользователя в 19:58, сеанс завершён штатно, RLS роли «Склад_ОформлениеОтгрузки» на проведение не влияла.

• 20:31 — на сервере приложений нашли фоновый процесс powershell.exe под svc_1c_sync; в списке соединений rphost строка с Usr=SyncBatch и Application=COMConnection, SessionID=9021.

• 20:38 — после завершения процесса и перезапуска рабочего процесса rphost монопольный режим установился за 12 секунд; обновление конфигурации базы данных завершилось без ошибок.

• 20:45 — параллельно проверили журнал регистрации на события «Обновление конфигурации» и «Доступ к данным»: записей о начале реструктуризации не появилось.

• 20:52 — откат не понадобился: реструктуризация не стартовала, таблицы Config и ConfigCAS не менялись; провели контрольное проведение «ПриходныйОрдер» и чтение регистра накопления «РезервыОтгрузки».

Вечернее окно cf и точка, где мастер остановился

Что видели пользователи

До 20:11 тонкий клиент работал без жалоб: кладовщики закрывали смену, диспетчеры сервиса проводили «ЗаказНаРемонт». В 20:17 диспетчер позвонил в сопровождение: «Система предупредила о перерыве, я вышел из 1С, почему окно висит?» На складе не было EXCP при проведении, только штатное сообщение платформы о скором обслуживании. После 20:38 обращений не поступало: в 21:00 регламентное задание «СинхронизацияОстатковWMS» отработало, исходящая очередь EnterpriseData не выросла. Утром бухгалтерия сверила регистр «ВзаиморасчётыСКлиентами» и документ «РеализацияТоваровУслуг» за ночь, расхождений не нашли.

Ложный след с пользователем Retail01 и управляемой формой списка «РеализацияТоваровУслуг» мы сняли через журнал регистрации и снимок консоли: интерактивных сеансов не оставалось, а в SQL Server не было удерживаемых блокировок на таблицах документов. Вторая ложная версия касалась «зависшего» rphost с нулевой CPU: процесс был жив, но без COM‑сессии в списке соединений его перезапуск не решил бы конфликт эксклюзивного режима, пока жив внешний Connect.

Коллеги из внедрения вспомнили похожий симптом на тестовой базе УТ 11, когда после сбоя обновления конфигурации обсуждали откат через dt. Здесь ситуация была уже: реструктуризация ещё не начиналась, конфигурация в SQL не успела перейти в промежуточное состояние, риск «половинчатой» схемы отсутствовал. Пользователи не видели сообщения «конфигурация базы данных не соответствует сохранённой», потому что несоответствия не возникло.

Фрагмент технологического журнала

20:19:04.227-90012,EXCP,2,level=ERROR,process=rphost,p:44102,t:55201,
Usr=SyncBatch,SessionID=9021,Application=COMConnection,
Exception=MonopolyMode,Descr='Не удалось установить монопольный режим'
20:19:04.228-90013,CONN,2,level=INFO,process=rphost,p:44102,t:55201,
Usr=SyncBatch,SessionID=9021,Connections=1
20:19:09.401-95002,ADM,2,level=INFO,process=rphost,p:44102,t:55201,
SessionID=9021,Action=SetMonopolyMode,Result=Fail

Для сравнения включили в logcfg.xml отбор по событию EXCP с порогом duration 0 на кластере app‑ka01, чтобы не пропускать короткие отказы монопольного режима при ночных cf. На графике метрик rphost за интервал 20:15–20:40 Connections=1 держался ровной линией, хотя счётчик «Активные сеансы» в консоли показывал 0.

Два счётчика: сеансы и соединения rphost

Корневая причина

Монопольный режим при обновлении конфигурации базы данных не освободил соединение V83.COMConnector: внешний скрипт импорта прайса WMS, запущенный планировщиком Windows на сервере приложений под учётной записью svc_1c_sync, оставил открытый Connect к информационной базе «СервисЗапчасти» после успешного обмена в 19:05. Конфигуратор корректно завершил интерактивные сеансы тонкого клиента, но COM‑сессия пользователя SyncBatch с ролью «ОбменWMS_ТолькоЧтение» не попала в привычный список «Сеансы» без колонки «Приложение» и не закрылась по команде мастера, потому что инициатор соединения находился вне процессов кластера 1С. Платформа многократно вызывала установку эксклюзивного доступа к метаданным на rphost и получала отказ, что выглядело как зависание шага без старта реструктуризации и без необходимости отката базы данных.

Что изменили

Минимальный воспроизводимый пример на копии базы мы собрали за один прогон около десяти минут. Подняли рабочий процесс rphost для копии «СервисЗапчасти_copy», создали пользователя SyncBatch, выполнили короткий powershell с COMConnector без освобождения объекта, затем из конфигуратора открыли «Обновление конфигурации базы данных» и получили тот же симптом: «Активных сеансов: 0», шаг монопольного режима не завершается. Достаточно было открыть в консоли администрирования 1С список соединений, включить колонку «Приложение», отфильтровать COMConnection и завершить сеанс, после чего мастер пошёл дальше без перезагрузки SQL Server.

В регламент сопровождения перед выкладкой cf/cfu добавили таблицу проверок: интерактивные сеансы, соединения COM и Designer, состояние регламентных заданий с флагом «использование», блокировка узла РИБ. На продуктиве для обмена WMS доработали общий модуль «ОбменWMSСервер»: явное обнуление COM‑объекта в блоке Исключение и запись в журнал регистрации события «ЗакрытиеCOMПослеОбмена» с номером сеанса.

Процедура ВыполнитьЗагрузкуПрайсаWMS() Экспорт
    Соединение = Неопределено;
    Попытка
        Соединение = Новый COMОбъект("V83.COMConnector");
        СтрокаПодключения = "Srvr=""app-ka01"";Ref=""ServisZapchasti"";Usr=""SyncBatch"";";
        COMБаза = Соединение.Connect(СтрокаПодключения);
        COMБаза.Обработки.ЗагрузкаПрайсаWMS.Создать().ВыполнитьОбмен();
    Исключение
        ЗаписьЖурналаРегистрации("ОбменWMS", УровеньЖурналаРегистрации.Ошибка,,,
            ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
        ВызватьИсключение;
    КонецПопытки;
    Если Соединение <> Неопределено Тогда
        Соединение = Неопределено;
    КонецЕсли;
КонецПроцедуры

Задания Windows на app‑ka01 перевели на запуск через агент кластера с параметром /C “ЗагрузкаПрайсаWMS”, чтобы не плодить COM на сервере приложений. Скрипт проверки (список SessionID с Application<>1CV8C) и описание инцидента лежат в репозитории ka25-update‑com‑session. На следующем окне обновления платформы тот же чек поймал сеанс Designer с терминального сервера ts-02, его завершили до мастера.

Цикл: импорт прайса держит Connect после обмена

Журнал регистрации после правки

20:55:03,ОбменWMS,Информация,,ЗакрытиеCOMПослеОбмена,Сеанс 9044 завершён штатно
21:00:11,РегламентноеЗадание.СинхронизацияОстатковWMS,Информация,,,Выполнено успешно
21:00:12,Контроль сеансов,,,Перед cf: COMConnection=0, Designer=0

На копии базы замерили длительность шага «Установка монопольного режима»: при «висящем» COM около 480 секунд до ручного снятия, после правки скрипта и чек‑листа 11–14 секунд при пустом списке соединений. Рестарт всего кластера не включали в регламент: достаточно завершить конкретный сеанс или процесс‑инициатор, затем при необходимости перезапустить один rphost, не трогая сеансы пользователей на других информационных базах того же сервера.

Запрос для сверки сеансов SQL (пример)

SELECT session_id, login_name, program_name, status
FROM sys.dm_exec_sessions
WHERE database_id = DB_ID(N'ServisZapchasti')
  AND is_user_process = 1;

Запрос не заменяет консоль 1С, но помогает отличить «хвост» ODBC/COM от служебных сеансов SQL Agent в момент, когда мастер обновления конфигурации базы данных уже открыт, а сомнения остаются.

Отдельно зафиксировали, чем этот инцидент не был: не блокировка регистра накопления «РезервыОтгрузки» (TLOCK в журнале отсутствовал), не конфликт RLS у роли «Склад_ОформлениеОтгрузки», не «залипший» сеанс HTTP‑сервиса мобильного клиента. Не помогла бы только перезагрузка SQL Server: соединение жило на стороне rphost и COM‑процесса. Обсуждение отката через выгрузку dt мы закрыли после проверки таблицы Config: версия метаданных в базе совпадала с сохранённой до запуска мастера.

После успешного cf команда сопровождения прогнала тот же сценарий на учебной базе без WMS: достаточно было оставить открытым конфигуратор на другой машине под тем же пользователем DomAdmin, чтобы увидеть Designer в списке соединений при нуле пользовательских сеансов. Это укрепило правило «смотреть соединения, а не только сеансы» для всех продуктивных информационных баз на app‑ka01, не только для «СервисЗапчасти».

Инженеры разработки добавили в хранилище комментарий к обработке «ЗагрузкаПрайсаWMS»: не вызывать Connect с сервера приложений в часы планового cf. Администраторы кластера включили оповещение по почте, если за пятнадцать минут до окна обновления конфигурации базы данных скрипт мониторинга находит Application=COMConnection. Так мы связали прикладной обмен WMS с платформенным требованием эксклюзивного режима, не смешивая проблему с настройкой СУБД или с правами роли «Администратор системы».

Текст powershell на продуктиве был коротким: создание COMConnector, Connect, вызов обработки, явный Exit 0 без обнуления переменной. Ошибка обмена в 19:05 не возникла, поэтому блок Исключение в обработке не выполнялся, а платформа не получала сигнал завершить сеанс. Именно «успешный» обмен оставил базу занятой для ночного cf.

Уроки

1. Нулевой счётчик активных сеансов в консоли кластера не равен готовности к обновлению конфигурации: COMConnection и сеансы Designer нужно проверять в списке соединений rphost, иначе эксклюзивный режим блокируется без видимого пользователя в форме.

2. Зависание на установке монопольного режима до начала реструктуризации не требует отката dt и не оставляет базу в «полуобновлённом» состоянии, но без разрыва скрытого Connect повторный запуск мастера воспроизводит тот же тупик.

3. Обмен через V83.COMConnector на сервере приложений переносят в регламентное задание 1С или сопровождают принудительным освобождением COM в коде; иначе ночной cf после «успешного» импорта прайса снова упирается в блокировку метаданных.