Отладка кода на сервере 1С 8.3: ключ -debug, порты и подключение из Конфигуратора

Чтобы подключить серверную отладку 1С, запустите агент сервера ragent с ключом -debug, перезапустите службу, а в Конфигураторе откройте Отладка → Подключение и включите автоматическое подключение к предмету «Сервер». Без ключа -debug точки останова в серверных процедурах просто не срабатывают: клиентский код отлаживается, серверный — нет.

Протоколов два. TCP — старый вариант, отладчик соединяется с рабочими процессами напрямую. HTTP — появился в 8.3.7, всё идёт через отдельный сервер отладки dbgs на одном порту (по умолчанию 1550). Для одной машины разработчика разницы почти нет. Если между вами и сервером брандмауэр или сервер стоит в другой сети — выбирайте HTTP: открыть один порт проще, чем диапазон.

1. Подготовка: версии платформы и тестовый кластер

Первое правило серверной отладки: не включайте её на рабочем сервере в часы, когда в базе работают люди. Если сработает точка останова в общем серверном модуле, остановится вызов того пользователя, чей код дошёл до этой строки. Человек увидит «зависшую» программу, а вы — чужие данные в окне отладчика.

Что проверить до начала:

• 🔢 Версия Конфигуратора совпадает с версией сервера до последней цифры. Конфигуратор 8.3.24.1467 не подключится к рабочим процессам сервера 8.3.24.1342. Номер сервера видно в консоли кластера или в пути к ragent.exe.
• 🖥️ Есть отдельный кластер или копия базы для отладки. Лучший вариант — тестовый сервер или второй экземпляр агента на другом порту с копией рабочей базы, выгруженной в .dt.
• 👤 У вас есть права администратора ОС на сервере. Без них не изменить параметры службы.
• 🔑 Вы знаете учётную запись администратора кластера, если она задана. Она понадобится, чтобы проверить параметры в консоли.

Узнать, включена ли отладка сейчас, можно по командной строке процесса ragent.

На Windows в PowerShell:

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

На Linux:

ps -ef | grep ragent

Если в строке запуска нет -debug, серверная отладка выключена.

2. Включение отладки на сервере Windows и Linux

Ключ -debug добавляется туда, откуда агент получает параметры запуска. На Windows это свойство службы, на Linux — скрипт или unit-файл systemd.

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

1. Откройте regedit и перейдите в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.
2. Найдите раздел службы агента 1С. Имя зависит от установки, например 1C:Enterprise 8.3 Server Agent (x86-64).
3. Откройте параметр ImagePath. Там примерно такая строка:

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

4. Допишите в конец -debug (для TCP) или -debug -http (для HTTP):

... -d "C:\Program Files\1cv8\srvinfo" -debug -http

5. Перезапустите службу в оснастке services.msc или командами:

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

Имя службы в командах должно совпадать с тем, что вы видите в services.msc.

💡 На тестовом стенде можно обойтись без правки реестра: остановите службу и запустите агент вручную из командной строки с теми же параметрами, но без -srvc и с ключом -debug. Окно консоли закрывать нельзя — вместе с ним остановится и сервер.

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

В установках со старым скриптом srv1cv83 параметры лежат в файле конфигурации службы (/etc/sysconfig/srv1cv83 в RHEL-подобных системах, /etc/default/srv1cv83 в Debian и Ubuntu). Отладку включает строка:

SRV1CV8_DEBUG=1

После правки: sudo systemctl restart srv1cv83 или sudo service srv1cv83 restart.

Новые версии платформы ставят unit-файл systemd с номером версии в имени. Удобнее всего переопределить строку запуска, не трогая исходный файл:

systemctl list-units | grep srv1cv8
sudo systemctl edit <имя-юнита>

В редакторе очистите ExecStart= и задайте его заново, скопировав исходную строку из systemctl cat <имя-юнита> и добавив -debug (или -debug -http). Затем sudo systemctl daemon-reload и рестарт юнита.

3. Права доступа и профиль безопасности

Отладка — это доступ к данным в обход интерфейса: в окне «Вычислить выражение» можно прочитать любой реквизит и выполнить запрос. Поэтому ограничения стоит продумать заранее.

Кто вообще может отлаживать. Отладчик работает из Конфигуратора. Войти туда может только пользователь с правом «Администрирование» или ролью «Полные права». Отдельного права «отлаживать сервер» в конфигурации нет — его заменяет доступ к Конфигуратору и сетевой доступ к портам.

Учётная запись службы. Агент обычно работает от USR1CV8 (Windows) или usr1cv8 (Linux). Отладка не требует расширять её права. Если служба после рестарта не поднимается — дело не в -debug, а в правах на каталог srvinfo или на путь к ragent.

Профиль безопасности базы. Если в консоли кластера у информационной базы задан профиль безопасности, внешние обработки и расширения работают в его ограничениях. Отладке это не мешает: точки останова срабатывают, но код может падать на операциях, запрещённых профилем (доступ к файлам, COM, внешним ресурсам). Отличайте эти ошибки от проблем отладчика.

4. Порты и брандмауэр для серверной отладки

Схема соединений в клиент-серверной 1С: клиент обращается к агенту (1540), затем к менеджеру кластера (1541) и к рабочим процессам — их диапазон задаётся в свойствах рабочего сервера, по умолчанию 1560–1591. Отладчик идёт тем же путём, а при HTTP добавляется сервер отладки.

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

Правило для Windows-брандмауэра на сервере (PowerShell от администратора):

New-NetFirewallRule -DisplayName "1C Debug HTTP" -Direction Inbound -Protocol TCP -LocalPort 1550 -RemoteAddress 192.168.10.0/24 -Action Allow

Для Linux с firewalld:

sudo firewall-cmd --permanent --add-port=1550/tcp
sudo firewall-cmd --reload

Порт и адрес сервера отладки можно задать ключами агента -debugServerAddr и -debugServerPort. Это нужно, когда у сервера несколько сетевых интерфейсов и dbgs слушает не тот адрес, к которому вы подключаетесь.

5. Как подключить отладчик к серверу из Конфигуратора

Сервер готов, теперь подключаемся со стороны разработчика.

Выбор протокола в Конфигураторе

Откройте Сервис → Параметры, вкладку «Отладка». Протокол отладки здесь должен совпадать с тем, что указан у агента: TCP с -debug/-debug -tcp, HTTP с -debug -http. Для HTTP укажите адрес сервера отладки вида http://srv1c:1550.

Автоподключение к серверным предметам

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

После старта клиента в окне «Предметы отладки» должна появиться строка с типом «Сервер». Если её нет — сервер не в режиме отладки или порты закрыты (см. последний раздел).

Если клиент запускается не из Конфигуратора

Например, отладка на компьютере пользователя через RDP. Тогда тонкий клиент запускают с ключом /DEBUG, а для HTTP передают адрес отладчика:

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /S"srv1c\buh_test" /DEBUG -http -attach /DEBUGGERURL "http://srv1c:1550"

Клиентский сеанс появится в «Предметах отладки», и вы подключитесь к нему вручную.

6. Отладка фоновых заданий, регламентных заданий и внешних обработок

С обычными серверными вызовами всё прозрачно. Сложности начинаются там, где код запускается без участия вашего клиента.

Фоновые и регламентные задания

Фоновое задание — отдельный сеанс на сервере. Отладчик к нему подключится, только если в автоподключении отмечен тип «Фоновое задание». Без этого точка останова в процедуре задания не сработает, даже если сервер в режиме отладки.

Приёмы, которые экономят время:

• ⏱️ Регламентное задание не ждите по расписанию. Откройте его в списке регламентных заданий базы (в типовых на БСП — Администрирование → Обслуживание → Регламентные операции → Регламентные и фоновые задания) и выполните вручную.
• 🧪 Вызывайте процедуру напрямую. Для отладки логики удобнее временно вызвать её из серверной процедуры обработки, а не через ФоновыеЗадания.Выполнить. Так вы отлаживаете ваш сеанс без поиска нужного задания.
• 🔒 Разберитесь, кто ещё выполняет задание. Если на кластере включены регламентные задания и в нём работают коллеги, ваша точка останова поймает и «чужой» запуск. В тестовой базе на время отладки лучше отключить лишние регламентные задания.

Внешние обработки и отчёты

Отладчик сопоставляет точку останова с файлом, который реально открыл клиент. Отсюда главный подвох:

1. Откройте файл .epf в Конфигураторе через Файл → Открыть и поставьте точки останова.
2. В клиенте, запущенном в режиме отладки, откройте этот же файл через Файл → Открыть.

Если обработка подключена в базу как дополнительная (через «Дополнительные отчеты и обработки»), платформа работает с её копией, сохранённой в базе. Точки, поставленные в файле на диске, на неё не попадут. Для отладки такую обработку открывайте из файла, а в базу загружайте уже исправленную версию.

Для расширений конфигурации проще: точки ставятся прямо в модулях расширения в Конфигураторе, отладка серверного кода работает как в основной конфигурации.

7. Диагностика ошибок подключения серверной отладки

Проверка порта с машины разработчика на Windows:

Test-NetConnection srv1c -Port 1550
Test-NetConnection srv1c -Port 1560

TcpTestSucceeded : True значит, что порт открыт. Если False — дело в брандмауэре или сеть режет трафик между подсетями.

Отдельно о режиме HTTP. Если в Конфигураторе выбран HTTP, а агент запущен с простым -debug (то есть TCP), подключение не установится, хотя всё остальное в порядке. Это самая частая причина после забытого рестарта службы.

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