Сервер 1С под Linux в режиме отладки: ключ -debug, протокол HTTP, туннель и логи

· 9 мин

Содержание

Чтобы включить отладку 1С на Linux, агент сервера ragent нужно запустить с ключом -debug (для отладки по HTTP — -debug -http) и перезапустить службу. Ставить что-то отдельно не требуется: отладчик встроен в Конфигуратор и EDT, а на сервере за него отвечает тот же ragent. Клиент для отладки запускают с ключом /debug или подключают из Конфигуратора через меню Отладка → Подключение.

Частое заблуждение — что в Linux серверная отладка «не работает » или требует особой сборки платформы. Работает так же, как в Windows. Отличаются только место, где задают параметры запуска (unit-файл systemd вместо свойств службы), права на каталоги и сетевые порты, которые часто закрыты файрволом.

Подготовка: версии платформы, пользователь службы и порты

Перед правкой службы проверьте три вещи. Большинство проблем с отладкой сервера 1С на Linux начинается именно здесь, а не в настройках Конфигуратора.

Версии должны совпадать до последней цифры

Конфигуратор, клиент и сервер должны быть одной сборки, например 8.3.24.1691 везде. Отладчик другой сборки к серверу не подключится.

Посмотреть установленные версии на сервере:

ls /opt/1cv8/x86_64/
ps -ef | grep -E 'ragent|rmngr|rphost' | grep -v grep

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

Пользователь и права

Служба по умолчанию работает от пользователя usr1cv8 (группа grp1cv8). Каталог данных кластера обычно лежит в /home/usr1cv8/.1cv8/1C/1cv8. Владельцем каталога и всех файлов в нём должен быть этот пользователь:

sudo ls -la /home/usr1cv8/.1cv8/1C/1cv8
sudo chown -R usr1cv8:grp1cv8 /home/usr1cv8/.1cv8

Для правки unit-файлов и логов нужен sudo. Для strace и gdb по чужому процессу — тоже root.

Порты

ПортКто слушаетНужен для
1540агент сервера ragentподключение клиентов и консоли
1541менеджер кластера rmngrработа кластера
1560–1591рабочие процессы rphostсеансы и отладка по TCP
1550сервер отладки dbgsотладка по HTTP

Диапазон рабочих процессов задаётся в свойствах рабочего сервера и может отличаться от стандартного. Проверить, что реально слушается:

sudo ss -tlnp | grep -E 'ragent|rmngr|rphost|dbgs'

Как включить отладку на сервере 1С в Linux

Способ зависит от того, как установлена служба. С 8.3.21 платформа ставит unit-файл systemd в каталог версии. В более старых установках служба запускалась скриптом /etc/init.d/srv1cv83.

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

Служба systemd (8.3.21 и новее)

  1. Найдите имя службы:
    systemctl list-units --type=service | grep -i 1cv8
    
    Обычно это что-то вроде srv1cv8-8.3.24.1691@default.service.
  2. Посмотрите, как сейчас собирается строка запуска:
    systemctl cat srv1cv8-8.3.24.1691@default
    
  3. Если в ExecStart подставляется переменная окружения для отладки (в штатном файле она называется SRV1CV8_DEBUG), задайте её через override, не трогая исходный файл:
    sudo systemctl edit srv1cv8-8.3.24.1691@default
    
    и впишите:
    [Service]
    Environment=SRV1CV8_DEBUG=-debug -http
    
    Для протокола TCP достаточно -debug.
  4. Если переменной нет, переопределите ExecStart целиком: сначала пустая строка ExecStart=, затем исходная команда из шага 2 с добавленным -debug.
  5. Примените и перезапустите:
    sudo systemctl daemon-reload
    sudo systemctl restart srv1cv8-8.3.24.1691@default
    ps -ef | grep ragent | grep -v grep
    

В выводе последней команды должен появиться ключ -debug. Override-файл живёт в /etc/systemd/system/<имя службы>.d/override.conf. При обновлении платформы имя службы меняется вместе с номером версии — override придётся перенести на новую службу.

Старый скрипт init.d

В установках до 8.3.21 параметры запуска лежат в файле конфигурации службы:

  • Debian и Ubuntu — /etc/default/srv1cv83;
  • RHEL, CentOS, Astra и подобные — /etc/sysconfig/srv1cv83.

Найдите в нём строку SRV1CV8_DEBUG, раскомментируйте и поставьте значение 1, затем перезапустите службу: sudo service srv1cv83 restart. Если файла нет, служба запускается со значениями по умолчанию, и строку можно создать.

TCP или HTTP: что выбрать

ПротоколКлюч сервераПлюсыМинусы
TCP-debugработает «из коробки» в локальной сетинужен доступ к портам рабочих процессов
HTTP-debug -httpодин порт 1550, проходит через туннель и проксипротокол нужно выбрать и в Конфигураторе

Для сервера в облаке или за NAT выбирайте HTTP. Для тестового стенда в одной сети подойдёт любой.

Как убедиться, что режим отладки включился

Проверка занимает минуту и избавляет от поиска проблемы в Конфигураторе, когда она на сервере:

  1. ps -ef | grep ragent | grep -v grep — в строке запуска есть -debug (и -http, если выбран HTTP).
  2. sudo ss -tlnp | grep dbgs — для HTTP-отладки процесс dbgs слушает порт 1550.
  3. sudo journalctl -u <имя службы> -n 50 — после рестарта нет сообщений об ошибках запуска.
  4. С машины разработчика порт доступен: nc -zv srv1c 1550 или nc -zv srv1c 1540.

Если первые три пункта в порядке, а четвёртый нет — дело в сети или файрволе, а не в 1С.

Отладка в клиенте: Конфигуратор, тонкий клиент, EDT

Серверная часть включена — теперь нужно, чтобы клиент 1С стал «предметом отладки» и подключился к отладчику.

Протокол в Конфигураторе

Откройте Сервис → Параметры, вкладку «Отладка». Там выбирается протокол отладки — он должен совпадать с тем, что задан на сервере. После смены протокола перезапустите Конфигуратор.

Дальше всё обычно: точка останова по F9, запуск из Конфигуратора по F5. Клиент, запущенный из Конфигуратора, подключается к отладчику сам.

Подключение к уже запущенному клиенту

Если клиент запущен отдельно, например на рабочем месте пользователя:

  1. В Конфигураторе откройте Отладка → Подключение.
  2. В списке появятся доступные предметы отладки: клиентские и серверные сеансы.
  3. Выберите нужный и нажмите «Подключить».

Чтобы серверные вызовы подключались без ручного выбора, в том же окне настройте автоматическое подключение и отметьте типы: сервер, тонкий клиент, фоновое задание и т.д.

Запуск клиента на Linux с ключом /debug

Клиентские приложения лежат рядом с сервером: 1cv8 (толстый клиент и Конфигуратор) и 1cv8c (тонкий клиент).

/opt/1cv8/x86_64/8.3.24.1691/1cv8c ENTERPRISE /S "srv1c/buh" /debug

Для HTTP-отладки с явным адресом отладчика:

/opt/1cv8/x86_64/8.3.24.1691/1cv8c ENTERPRISE /S "srv1c/buh" \
  /debug -http -attach /DebuggerURL "http://srv1c:1550"

Ключ -attach сразу подключает клиент к отладчику по указанному адресу.

💡 В EDT отладка настраивается через конфигурацию отладки (Debug Configurations): там указывают информационную базу и адрес сервера отладки. Серверная часть та же: ragent с -debug -http.

Логи и технологический журнал 1С в Linux

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

Журнал службы

sudo journalctl -u srv1cv8-8.3.24.1691@default -n 200 --no-pager
sudo journalctl -u srv1cv8-8.3.24.1691@default -f

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

Технологический журнал: logcfg.xml

Техжурнал включают файлом logcfg.xml в каталоге conf платформы: общий — /opt/1cv8/conf/, или каталог conf внутри конкретной версии. Платформа перечитывает файл примерно раз в минуту, перезапуск не нужен.

Минимальный пример — исключения и дампы:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="/var/log/1c/techlog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
  <dump create="true" location="/var/log/1c/dumps" type="3"/>
</config>

Каталоги создайте заранее и отдайте пользователю службы:

sudo mkdir -p /var/log/1c/techlog /var/log/1c/dumps
sudo chown -R usr1cv8:grp1cv8 /var/log/1c

Следите за местом на диске: техжурнал с широким фильтром за час может вырасти на гигабайты. Параметр history задаёт, сколько часов хранить файлы.

Журнал регистрации

Журнал регистрации базы лежит в каталоге данных кластера: /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/<GUID базы>/1Cv8Log. Смотреть его удобнее из самой 1С, а вот размер каталога и права проверяют уже из консоли.

Удалённая отладка через SSH-туннель

Типичная ситуация: сервер 1С в облаке, наружу открыт только SSH, а Конфигуратор у разработчика на ноутбуке. Отладка по HTTP решает задачу одним туннелем.

  1. На сервере ragent запущен с -debug -http, сервер отладки слушает 1550.
  2. На своей машине пробросьте порт:
    ssh -N -L 1550:127.0.0.1:1550 admin@srv1c.example.ru
    
    В Windows то же самое делает встроенный OpenSSH или PuTTY (раздел туннелей).
  3. В Конфигураторе выберите протокол HTTP и укажите сервер отладки http://localhost:1550.
  4. Клиент для отладки запускайте с /debug -http -attach /DebuggerURL "http://localhost:1550".

Отладка по TCP через один туннель обычно не заводится: рабочие процессы используют диапазон портов, и каждый пришлось бы пробрасывать отдельно. Не открывайте 1550 и диапазон рабочих процессов в интернет напрямую — только туннель или VPN.

Когда с одним сервером работают несколько разработчиков, каждый поднимает свой туннель на свой локальный порт. Удобнее всего прописать проброс в ~/.ssh/config строкой LocalForward 1550 127.0.0.1:1550 для нужного хоста — тогда туннель поднимается обычной командой ssh srv1c.

Если в Конфигураторе нет предметов отладки, проверьте на сервере ss -tlnp | grep 1550. Пусто — значит, сервер отладки не поднялся, смотрите journalctl.

Когда отладчика мало: strace и gdb

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

strace: что процесс делает прямо сейчас

pgrep -a rphost
sudo strace -f -tt -p <PID> -e trace=network,file -o /tmp/rphost.strace

По файлу видно, к какому адресу процесс ждёт ответа (часто это СУБД или сервер лицензирования) и какой файл не может открыть из-за прав. Остановка — Ctrl+C.

💡 strace заметно замедляет процесс. Держите его включённым минуты, а не часы.

gdb: стек зависшего процесса

sudo gdb -p <PID> -batch -ex "thread apply all bt" > /tmp/rphost_bt.txt

Команда снимает стеки всех потоков и сразу отключается. Готовый дамп можно снять командой gcore <PID>.

Пока gdb или gcore подключён, процесс полностью остановлен: у всех пользователей этого rphost сеансы «замрут». На рабочем сервере делайте это, только когда процесс и так завис, и предупредите пользователей.

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

Почему отладка не подключается: разбор ошибок

Диагностика: выберите симптом

Отдельно про файрвол. В Ubuntu проверьте sudo ufw status, в RHEL-подобных — sudo firewall-cmd --list-all. Открывать порты лучше только для адресов разработчиков, а не для всех.

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

Можно ли отлаживать на рабочем сервере?
Можно, но кратко и вне пиковой нагрузки. Включение и выключение отладки требует перезапуска службы, а остановка на точке останова держит сеанс и его блокировки.
Нужна ли отдельная лицензия для отладки?
Нет. Отладчик входит в Конфигуратор, а клиентский сеанс в режиме отладки занимает лицензию как обычный.
Отладка работает в файловой базе на Linux?
Да. Клиент запускают из Конфигуратора или с ключом /debug; серверная часть с ragent не нужна, код выполняется в процессе клиента.
Сохранится ли ключ -debug после обновления платформы?
Нет, если override был привязан к службе старой версии. У новой версии своё имя службы, настройку нужно повторить.
Как выключить отладку обратно?
Удалите override командой systemctl revert с именем службы или уберите ключ из переменной, затем daemon-reload и restart.