Сервер 1С под Linux в режиме отладки: ключ -debug, протокол HTTP, туннель и логи
Содержание
Чтобы включить отладку 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 и новее)
- Найдите имя службы:Обычно это что-то вроде
systemctl list-units --type=service | grep -i 1cv8srv1cv8-8.3.24.1691@default.service. - Посмотрите, как сейчас собирается строка запуска:
systemctl cat srv1cv8-8.3.24.1691@default - Если в
ExecStartподставляется переменная окружения для отладки (в штатном файле она называетсяSRV1CV8_DEBUG), задайте её через override, не трогая исходный файл:и впишите:sudo systemctl edit srv1cv8-8.3.24.1691@defaultДля протокола TCP достаточно[Service] Environment=SRV1CV8_DEBUG=-debug -http-debug. - Если переменной нет, переопределите
ExecStartцеликом: сначала пустая строкаExecStart=, затем исходная команда из шага 2 с добавленным-debug. - Примените и перезапустите:
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. Для тестового стенда в одной сети подойдёт любой.
Как убедиться, что режим отладки включился
Проверка занимает минуту и избавляет от поиска проблемы в Конфигураторе, когда она на сервере:
ps -ef | grep ragent | grep -v grep— в строке запуска есть-debug(и-http, если выбран HTTP).sudo ss -tlnp | grep dbgs— для HTTP-отладки процессdbgsслушает порт 1550.sudo journalctl -u <имя службы> -n 50— после рестарта нет сообщений об ошибках запуска.- С машины разработчика порт доступен:
nc -zv srv1c 1550илиnc -zv srv1c 1540.
Если первые три пункта в порядке, а четвёртый нет — дело в сети или файрволе, а не в 1С.
Отладка в клиенте: Конфигуратор, тонкий клиент, EDT
Серверная часть включена — теперь нужно, чтобы клиент 1С стал «предметом отладки» и подключился к отладчику.
Протокол в Конфигураторе
Откройте Сервис → Параметры, вкладку «Отладка». Там выбирается протокол отладки — он должен совпадать с тем, что задан на сервере. После смены протокола перезапустите Конфигуратор.
Дальше всё обычно: точка останова по F9, запуск из Конфигуратора по F5. Клиент, запущенный из Конфигуратора, подключается к отладчику сам.
Подключение к уже запущенному клиенту
Если клиент запущен отдельно, например на рабочем месте пользователя:
- В Конфигураторе откройте
Отладка → Подключение. - В списке появятся доступные предметы отладки: клиентские и серверные сеансы.
- Выберите нужный и нажмите «Подключить».
Чтобы серверные вызовы подключались без ручного выбора, в том же окне настройте автоматическое подключение и отметьте типы: сервер, тонкий клиент, фоновое задание и т.д.
Запуск клиента на 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 решает задачу одним туннелем.
- На сервере
ragentзапущен с-debug -http, сервер отладки слушает 1550. - На своей машине пробросьте порт:В Windows то же самое делает встроенный OpenSSH или PuTTY (раздел туннелей).
ssh -N -L 1550:127.0.0.1:1550 admin@srv1c.example.ru - В Конфигураторе выберите протокол HTTP и укажите сервер отладки
http://localhost:1550. - Клиент для отладки запускайте с
/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. Открывать порты лучше только для адресов разработчиков, а не для всех.