Серверная отладка в 1С 8.3: ключ -debug, предметы отладки и фоновые задания

Чтобы запустить отладку на сервере 1С, агент сервера (ragent) должен стартовать с ключом -debug. По умолчанию его нет. Пока ключа нет, точки останова в серверных процедурах, фоновых и регламентных заданиях не срабатывают: конфигуратор просто не видит серверных предметов отладки.

Порядок такой: добавить -debug в параметры службы, перезапустить агент, в конфигураторе выбрать протокол отладки и включить автоматическое подключение серверных предметов. Всё это относится к платформе 8.3 в клиент-серверном варианте и не зависит от конфигурации: БП, ЗУП и УТ отлаживаются одинаково.

Что проверить перед включением серверной отладки

Начните с вопроса, нужна ли серверная отладка вообще. В файловой базе серверный код выполняется в процессе клиента, и отладчик ловит его без всяких ключей. Ключ -debug нужен только там, где работает кластер серверов 1С.

Для работы понадобятся три вида доступа:

• 🖥️ права локального администратора на сервере 1С — чтобы изменить параметры службы и перезапустить её;
• 🔑 администратор кластера (если он задан) — для консоли кластера и утилиты rac;
• 👤 пользователь информационной базы с правом открывать конфигуратор, обычно роль «Полные права» или «Администратор системы».

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

Лучший вариант — отдельный тестовый сервер или хотя бы отдельный кластер с копией базы. Держать -debug на рабочем сервере постоянно не стоит: процессы работают чуть медленнее, а к серверному коду может подключиться любой, у кого есть конфигуратор и доступ по сети.

Как включить отладку на сервере 1С: ключ -debug у агента

Протокол: TCP/IP или HTTP

Платформа 8.3 умеет два протокола отладки. Выбор влияет на строку запуска агента и на настройки конфигуратора.

Протокол в конфигураторе и в строке агента должен совпадать. Если агент запущен с -debug -http, а в конфигураторе выбран TCP/IP, серверных предметов вы не увидите.

Windows: параметры службы агента

Агент сервера в Windows работает как служба 1C:Enterprise 8.3 Server Agent (x86-64) (у 32-битной версии имя без суффикса). Посмотреть текущую строку запуска:

sc qc "1C:Enterprise 8.3 Server Agent (x86-64)"

В выводе найдите строку BINARY_PATH_NAME. Обычно она выглядит так:

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

Добавить ключ удобнее всего через реестр:

1. Остановите службу агента в оснастке services.msc.
2. Запустите regedit и откройте ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent (x86-64).
3. Откройте параметр ImagePath.
4. Сразу после закрывающей кавычки пути к ragent.exe допишите -debug (или -debug -http).
5. Сохраните и запустите службу.
6. Снова выполните sc qc и убедитесь, что ключ на месте.

Итоговая строка:

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

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

Здесь всё зависит от того, как установлена служба.

• 🐧 Старый init-скрипт srv1cv83. Настройки лежат в /etc/sysconfig/srv1cv83 (RHEL-подобные) или /etc/default/srv1cv83 (Debian, Ubuntu). Раскомментируйте строку SRV1CV8_DEBUG=1 и перезапустите службу.
• 🐧 Юнит systemd в новых версиях платформы. Посмотрите юнит командой systemctl cat с именем вашей службы и найдите строку ExecStart с ragent. Добавьте ключ через systemctl edit: в override сначала пустая строка ExecStart=, затем полная строка запуска с -debug.

systemctl list-units | grep -i 1c
sudo systemctl edit <имя_службы>
sudo systemctl restart <имя_службы>
ps aux | grep ragent

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

Как выключить отладку после работы

Когда задача решена, верните строку запуска в исходный вид: уберите -debug (и -http, если добавляли) из ImagePath или из override systemd. Затем перезапустите службу в тихое время, ведь сеансы снова оборвутся. Так рабочий сервер не останется открытым для подключения отладчика.

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

Настройка протокола в конфигураторе

Откройте Сервис → Параметры → Отладка. Там выбирается протокол отладки для этой информационной базы и адрес сервера отладки при HTTP. Для локального сервера отладки адрес можно оставить по умолчанию: конфигуратор сам запускает dbgs на своей машине.

Если сервер отладки работает на другой машине, укажите адрес вида http://server1c:1550 и откройте этот порт в брандмауэре.

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

Запустите отладку клавишей F5 или командой Отладка → Начать отладку. Затем откройте Отладка → Подключение. Появится окно «Предметы отладки» со списком процессов, к которым можно подключиться.

Чтобы точки останова в серверных модулях срабатывали, включите автоматическое подключение:

1. В окне «Предметы отладки» нажмите кнопку автоматического подключения.
2. Отметьте серверные предметы и фоновые задания.
3. Сохраните настройку.
4. Поставьте точку останова в процедуре с директивой &НаСервере или в общем модуле с флагом «Сервер».
5. В клиенте выполните действие, которое вызывает эту процедуру.

Если всё настроено, выполнение остановится на нужной строке, а в окне предметов появится серверный процесс.

Утилита RAS и rac: какой рабочий процесс отлаживать

Сразу развею миф: RAS не включает отладку. Сервер администрирования (ras) нужен, чтобы управлять кластером из командной строки утилитой rac. Для отладки он полезен как инструмент разведки: какой рабочий процесс занят, какой сеанс висит, сколько памяти съедено.

Запуск RAS вручную на сервере 1С:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\ras.exe" cluster --port=1545 localhost:1540

Дальше с любой машины, где установлена платформа той же версии:

rac server1c:1545 cluster list
rac server1c:1545 process list --cluster=<uuid_кластера>
rac server1c:1545 session list --cluster=<uuid_кластера>

Что это даёт при отладке:

• 🔎 process list показывает рабочие процессы, их PID и порт. По PID в «Диспетчере задач» видно, какой rphost нагружен;
• 🔎 session list показывает сеансы и их приложения, в том числе фоновые задания. Так вы поймёте, запущено ли задание вообще;
• 🔎 при заданном администраторе кластера добавляйте параметры авторизации; их точные имена смотрите в rac help cluster.

Чтобы RAS работал постоянно, его регистрируют отдельной службой. Ключ -debug к RAS отношения не имеет и в его строку не добавляется.

Отладка фоновых и регламентных заданий на сервере

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

Как поймать регламентное задание

1. Включите в автоподключении фоновые задания.
2. Поставьте точку останова в процедуре, которая указана в свойстве «Имя метода» регламентного задания.
3. Не ждите расписания. В БП 3.0 и ЗУП 3.1 откройте Администрирование → Обслуживание, найдите «Регламентные и фоновые задания», выберите задание и запустите его вручную.
4. Отладчик остановится в серверном процессе.

Если задание не запускается вовсе

Проверьте два флага:

• ⛔ у информационной базы в консоли кластера включена «Блокировка регламентных заданий» — тогда задания не стартуют;
• ⛔ у самого задания снят флаг «Использование» — расписание игнорируется.

Приём: вызов метода из обработки

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

&НаСервере
Процедура ВыполнитьНаСервере()
	// Метод общего модуля, указанный в регламентном задании
	ОбновлениеКурсов.ЗагрузитьКурсыВалют();
КонецПроцедуры

Отличие одно: задание обычно работает от имени пользователя, указанного в его настройках, а обработка — от вашего. Если ошибка связана с правами, этот приём её не воспроизведёт.

Технологический журнал: когда отладчик не помогает

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

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

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

Что здесь важно:

• 📁 location — каталог для логов. Выберите диск с запасом места: журнал растёт быстро;
• ⏳ history — сколько часов хранить файлы;
• 🧩 событие EXCP — исключения. Для поиска долгих серверных вызовов добавляют событие CALL, для запросов — DBMSSQL или DBPOSTGRS.

В логах ищите строку с текстом ошибки и смотрите поле контекста: там указан модуль и строка кода. Дальше ставите точку останова ровно туда и воспроизводите случай уже под отладчиком.

Есть и вариант попроще — журнал регистрации базы: Администрирование → Обслуживание → Журнал регистрации. Он показывает ошибки фоновых заданий с текстом исключения. Начинать диагностику лучше с него.

Почему отладка на сервере 1С не запускается

Ещё одна частая причина — разные сборки платформы на сервере и у разработчика. Конфигуратор 8.3.xx.1111 не подключится к кластеру 8.3.xx.2222, даже если ключ -debug стоит верно.

Частые вопросы об отладке на сервере