Отладка серверного кода 1С 8.3: флаг -debug, ras и техжурнал

Отладчик на сервере 1С 8.3 включается одним ключом: в строку запуска агента сервера ragent добавляют -debug, после чего службу перезапускают. Без этого ключа Конфигуратор видит только клиентские предметы отладки, а точки останова в серверных процедурах и модулях с &НаСервере не срабатывают.

Есть два режима. TCP (-debug или -debug -tcp) — старый, работает через порты кластера. HTTP (-debug -http) — через сервер отладки dbgs, удобнее, когда между разработчиком и сервером стоит файрвол. Для новой платформы обычно выбирают HTTP, TCP оставляют для совместимости со старыми привычками команды.

Подготовка: что нужно до включения отладки

Включение отладки — это изменение параметров службы и её перезапуск. Значит, нужны права и окно для работ.

• 🔑 Права локального администратора на сервере 1С (Windows) или sudo (Linux) — чтобы править службу.
• 👤 Администратор кластера — если кластер защищён паролем, он понадобится для rac.
• 🧩 Одинаковая версия платформы у Конфигуратора разработчика и у сервера. При разных номерах сборки отладчик не подключится.
• 🌐 Сетевой доступ: от машины разработчика к серверу по порту агента 1540, менеджера кластера 1541 и диапазону рабочих процессов (по умолчанию 1560–1591). Для HTTP-режима — ещё порт сервера отладки, по умолчанию 1550.
• ⏰ Окно для перезапуска. Остановка агента обрывает сеансы всех пользователей всех баз на этом сервере.

Перед изменениями зафиксируйте текущую строку запуска службы. Её легко восстановить, если что-то пойдёт не так.

Get-CimInstance Win32_Process -Filter "name='ragent.exe'" | Select-Object ProcessId, CommandLine

Включаем отладку на сервере: ragent и каталог srvinfo

Каталог srvinfo (по умолчанию C:\Program Files\1cv8\srvinfo) — это реестр кластера. Там лежат список кластеров 1CV8Clst.lst, каталог reg_1541 с данными баз и журналами регистрации. Флага отладки в этих файлах нет, и редактировать их вручную не нужно: испорченный реестр кластера чинится только восстановлением из копии.

Путь к srvinfo передаётся агенту ключом -d. Рядом с ним в той же строке запуска и ставится -debug.

Windows: правим параметры службы

1. Узнайте имя службы агента. Для 64-битной платформы оно обычно выглядит как 1C:Enterprise 8.3 Server Agent (x86-64), но при установке нескольких версий может отличаться.
2. Откройте regedit и перейдите в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<имя службы>.
3. Откройте параметр ImagePath. Добавьте -debug (или -debug -http) сразу после пути к ragent.exe.
4. Перезапустите службу через services.msc или командами ниже.

Строка до и после:

"C:\Program Files\1cv8\8.3.24.1548\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo"

"C:\Program Files\1cv8\8.3.24.1548\bin\ragent.exe" -debug -http -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo"

Перезапуск из командной строки администратора:

net stop "1C:Enterprise 8.3 Server Agent (x86-64)"
net start "1C:Enterprise 8.3 Server Agent (x86-64)"

Linux: systemd или старый init-скрипт

На платформах с systemd-юнитом (новые сборки ставят его в каталог платформы под /opt/1cv8/) порядок такой:

# посмотреть текущую команду запуска
systemctl cat srv1cv8-8.3.24.1548@default
# создать переопределение
sudo systemctl edit srv1cv8-8.3.24.1548@default

В открывшемся файле переопределите ExecStart: сначала пустая строка ExecStart=, затем исходная команда из systemctl cat с добавленным -debug. Сохраните и выполните sudo systemctl daemon-reload && sudo systemctl restart <юнит>.

Если сервер запущен старым скриптом srv1cv83, отладку включает переменная SRV1CV8_DEBUG=1 в файле /etc/sysconfig/srv1cv83 (RHEL-подобные системы) или /etc/default/srv1cv83 (Debian, Ubuntu). После правки — sudo systemctl restart srv1cv83.

Проверяем, что флаг применился

Повторите команду Get-CimInstance из подготовки или ps -ef | grep ragent в Linux. В строке должен появиться -debug. Если его нет — служба запустилась со старыми параметрами, обычно потому, что правили не ту службу из нескольких установленных.

Подключаем Конфигуратор к серверной отладке

1. Откройте базу в Конфигураторе.
2. В параметрах Конфигуратора (Сервис → Параметры) выберите тот же протокол отладки, что и на сервере: TCP или HTTP.
3. Запустите клиент через меню Отладка → Начать отладку — тонкий клиент сам подключится к отладчику.
4. Откройте Отладка → Подключение. В списке должны быть предметы отладки с типом «Сервер». Если их нет — нажмите кнопку автоматического подключения и отметьте серверные предметы.
5. Поставьте точку останова в серверной процедуре (F9) и выполните действие в клиенте.

Для HTTP-режима при запуске клиента вручную нужен адрес сервера отладки. Его передают в параметрах запуска базы (Изменить → Дополнительно → Дополнительные параметры запуска):

/DEBUG -http -attach /DEBUGGERURL http://dev-pc:1550

Здесь dev-pc — машина разработчика, где Конфигуратор держит сервер отладки. Порт 1550 должен быть открыт во входящих правилах её файрвола.

Утилита ras и консоль rac: смотрим сеансы и процессы

ras — сервер администрирования, rac — консольный клиент к нему. Вместе они показывают, какие рабочие процессы живут, сколько памяти держат и какие сеансы к ним прицеплены. При отладке это нужно, чтобы понять, в каком rphost выполняется ваш вызов и не завис ли сеанс после остановки.

Запуск ras вручную на сервере:

cd "C:\Program Files\1cv8\8.3.24.1548\bin"
ras.exe cluster --port=1545 localhost:1540

Чтобы он работал постоянно, его регистрируют службой:

sc create "1C:Enterprise 8.3 Remote Server" binPath= "\"C:\Program Files\1cv8\8.3.24.1548\bin\ras.exe\" cluster --service --port=1545 localhost:1540" start= auto

Основные команды rac:

rac.exe localhost:1545 cluster list
rac.exe localhost:1545 process list --cluster=<uuid кластера>
rac.exe localhost:1545 session list --cluster=<uuid кластера>

Если кластер защищён, добавьте --cluster-user и --cluster-pwd. Остальные ключи уточняйте через rac help <режим> — набор параметров отличается между сборками.

Логи рабочих процессов rphost: техжурнал вместо догадок

Отладчик показывает ход выполнения, но не всегда ловит падение процесса или ошибку, которая возникает раз в сутки. Для этого включают технологический журнал — файл logcfg.xml.

Файл кладут в каталог conf платформы: C:\Program Files\1cv8\conf\ (общий для всех версий) или bin\conf конкретной версии. Перезапуск службы не нужен: платформа перечитывает настройки примерно раз в минуту.

Минимальная настройка для поиска ошибок:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\v8logs" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

• 📁 В D:\v8logs появятся каталоги rphost_<PID>, rmngr_<PID>, ragent_<PID>.
• 🕐 Внутри — файлы по часам с именами вида 26100714.log (год, месяц, день, час).
• 🔁 history="24" — хранить 24 часа, старые файлы удаляются сами.
• 🧯 Событие EXCP — исключения. Для разбора медленных вызовов добавляют CALL с отбором по длительности, но такой журнал быстро растёт.

Записи читаются блокнотом: в каждой строке время, длительность, имя события и свойства, в том числе Descr с текстом ошибки и Context со стеком встроенного языка. По Context видно модуль и номер строки — туда и ставят точку останова.

Не путайте техжурнал с журналом регистрации базы. Журнал регистрации лежит в srvinfo\reg_1541\<UUID базы>\1Cv8Log и смотрится из Конфигуратора или клиента. Он показывает бизнес-события и ошибки пользователей, но не внутренности процесса.

Отладка внешних соединений и COM-объектов

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

• 🖥️ Серверные вызовы идут в рабочий процесс кластера. Их ловит та же серверная отладка, ключ -debug уже даёт к ним доступ.
• 📦 Сама COM-сторона живёт в процессе вызывающей программы. Если это 1С, процессом будет её rphost или клиент; если внешняя программа — её собственный процесс; если COM+-приложение — dllhost.exe.

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

Типичные ловушки:

• 🔢 Разные версии. Зарегистрированная comcntr.dll должна быть той же сборки, что и сервер. После обновления платформы её перерегистрируют: regsvr32 "C:\Program Files\1cv8\8.3.24.1548\bin\comcntr.dll" от имени администратора.
• 🧮 Разрядность. 32-битная программа не увидит 64-битный COM-коннектор, и наоборот.
• 👻 Висящие соединения. Скрипт, который не освободил объект соединения, оставляет сеанс в кластере. Его видно в rac session list — приложение будет помечено как COM-соединение.

Завершаем отладку и возвращаем сервер в рабочий режим

Оставлять -debug на рабочем сервере после разбора проблемы не стоит. Порядок отката:

1. В Конфигураторе откройте Отладка → Список точек останова, удалите все точки и отключитесь от предметов отладки.
2. Удалите -debug и -http из ImagePath службы или из переопределения systemd (sudo systemctl revert <юнит> удалит его целиком).
3. Предупредите пользователей и перезапустите агент сервера — сеансы оборвутся.
4. Удалите или переименуйте logcfg.xml, если включали техжурнал. Иначе он продолжит писать на диск.
5. Через пару минут очистите каталог журнала. Пока процесс держит файл, удалить его не получится.
6. Проверьте строку запуска ragent той же командой, что и при подготовке: -debug в ней быть не должно.

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