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

Чтобы включить отладку на сервере 1С под Linux, агент сервера ragent нужно перезапустить с ключом -debug. В systemd это делается через переопределение юнита службы, в старой схеме с init.d — параметром SRV1CV8_DEBUG=1 в файле настроек службы. После перезапуска в Конфигураторе появятся серверные предметы отладки, и точки останова в серверных процедурах начнут срабатывать.

Типичная ситуация: разработчик ставит точку останова в модуле объекта, проводит документ из клиента, а отладчик молчит. Файловая база на ноутбуке отлаживается без вопросов, а серверная на Linux — нет. Причина почти всегда одна: кластер запущен без режима отладки. Если же нужен не отладчик кода, а диагностика зависшего rphost, пригодятся технологический журнал, strace и GDB.

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

Перед правкой конфигурации службы выясните три вещи.

🔍 Как запущен сервер. Начиная с платформы 8.3.21 сервер под Linux ставится как юнит systemd, имя юнита содержит номер версии. В более ранних установках используется скрипт /etc/init.d/srv1cv83. Проверка:

systemctl list-units --type=service | grep -i 1cv8
ls /etc/init.d/ | grep -i 1cv8

🔍 С какими ключами работает агент сейчас. Посмотрите командную строку процесса:

ps -eo pid,user,args | grep [r]agent

Если в строке уже есть -debug, режим включён, и проблема в другом (порты, протокол, настройки Конфигуратора).

🔍 Права. Процессы ragent, rmngr и rphost работают от пользователя usr1cv8 (группа grp1cv8). Для правки юнита и перезапуска службы нужен root или sudo. Для strace и gdb — тоже root: обычный пользователь не сможет подключиться к чужому процессу.

Проверьте ограничение ptrace в ядре:

cat /proc/sys/kernel/yama/ptrace_scope

Значение 0 или 1 подходит для работы под root. Значение 3 запрещает подключение к процессам совсем — до перезагрузки его не снять.

Включение режима отладки сервера 1С: ключ -debug для ragent

Если служба работает через systemd

Сначала посмотрите текущий юнит целиком:

systemctl cat srv1cv8-8.3.xx.xxxx@default.service

Подставьте точное имя из вывода systemctl list-units. В юнитах новых версий ключи запуска собираются из переменных окружения Environment=, среди них есть переменная для режима отладки. Если она есть, достаточно задать её в переопределении:

sudo systemctl edit srv1cv8-8.3.xx.xxxx@default.service

В открывшемся редакторе:

[Service]
Environment=SRV1CV8_DEBUG=-debug

Если переменной в юните нет, переопределите строку запуска целиком. Сначала очистите исходную ExecStart=, затем скопируйте её из systemctl cat и допишите -debug:

[Service]
ExecStart=
ExecStart=/opt/1cv8/x86_64/8.3.xx.xxxx/ragent -daemon -port 1540 -regport 1541 -range 1560:1591 -debug

Правка через systemctl edit лежит в отдельном каталоге .d и переживает обновление пакета. Не редактируйте исходный файл юнита напрямую: при обновлении платформы его перезапишут.

Применение:

sudo systemctl daemon-reload
sudo systemctl restart srv1cv8-8.3.xx.xxxx@default.service
ps -eo args | grep [r]agent

В выводе последней команды должен появиться -debug.

Если служба работает через init.d

Скрипт srv1cv83 читает настройки из файла /etc/default/srv1cv83 (Debian, Ubuntu) или /etc/sysconfig/srv1cv83 (RHEL-подобные системы). Найдите строку с SRV1CV8_DEBUG, раскомментируйте её и задайте 1:

SRV1CV8_DEBUG=1

Затем перезапустите службу: sudo /etc/init.d/srv1cv83 restart.

Протокол отладки: TCP или HTTP

У отладки 1С два протокола. Ключ -debug без уточнений включает TCP. Для HTTP-отладки добавляют -http: -debug -http. Протокол на сервере и в Конфигураторе должен совпадать.

Открыть порты в ufw:

sudo ufw allow from 10.0.0.0/24 to any port 1560:1591 proto tcp

Разрешайте доступ только из сети разработчиков, а не со всего интернета.

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

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

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

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

Отладчик показывает выполнение кода. Если же нужно понять, почему тормозит или падает rphost, первым инструментом идёт технологический журнал (ТЖ). Он не требует перезапуска сервера и ключа -debug.

Настройки лежат в файле logcfg.xml. На Linux его кладут в каталог conf платформы: общий /opt/1cv8/conf/ или каталог конкретной версии /opt/1cv8/x86_64/8.3.xx.xxxx/conf/. Сервер перечитывает файл примерно раз в минуту.

Минимальная настройка для поиска исключений и долгих вызовов:

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

Подготовьте каталоги и права:

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

📌 history="24" — хранить 24 часа логов, старые удаляются сами. 📌 В актуальных версиях 8.3 длительность (duration) в журнале — в микросекундах, так что 1000000 отбирает вызовы дольше 1 секунды. 📌 Элемент <dump> включает создание дампов при аварийном завершении процессов.

Трассировка системных вызовов rphost через strace

Когда rphost «висит» без нагрузки на процессор, ТЖ часто молчит: процесс ничего не выполняет, он чего-то ждёт. strace показывает, на каком системном вызове он застрял.

Найдите нужный рабочий процесс:

pgrep -a rphost
top -p $(pgrep -d, rphost)

Подключитесь к нему на 30 секунд и запишите трассу в файл:

sudo timeout 30 strace -f -tt -T -p <PID> -o /tmp/rphost.strace

• -f — следить за всеми потоками процесса, у rphost их десятки;
• -tt — время с микросекундами;
• -T — сколько длился каждый вызов;
• -e trace=network,file — сузить вывод до сети и файлов, если трасса слишком большая.

Что искать в результате:

• 🌐 долгие poll, recvfrom, read на сетевом сокете — процесс ждёт ответа СУБД или другого сервера;
• 🔒 futex с большим временем — ожидание блокировки между потоками;
• 📁 open/openat с ответом EACCES или ENOENT — нет прав или нет файла (часто временный каталог или каталог ТЖ);
• 🔁 одинаковые вызовы тысячами подряд — цикл с ошибкой.

Номер сокета из трассы сопоставьте с соединением через ss -tnp | grep <PID> — так видно, к какому адресу и порту ушёл запрос.

Дампы памяти rphost и разбор в GDB

Дамп нужен в двух случаях: процесс падает (нужен посмертный снимок) или процесс завис (нужен снимок состояния без остановки).

Разрешить создание core-файлов

Для службы systemd лимит задаётся в том же переопределении юнита:

[Service]
LimitCORE=infinity

Куда пишется файл, определяет /proc/sys/kernel/core_pattern. Если там стоит обработчик systemd-coredump, дампы смотрят командой:

coredumpctl list rphost
coredumpctl dump <PID> -o /var/log/1c/dumps/rphost.core

Снять дамп с работающего процесса

sudo gcore -o /var/log/1c/dumps/rphost <PID>

Утилита входит в пакет gdb. Процесс на время снятия дампа останавливается: на рабочем процессе с 10–20 ГБ памяти это десятки секунд, пользователи этого процесса в это время ждут.

Что посмотреть в GDB

gdb /opt/1cv8/x86_64/8.3.xx.xxxx/rphost /var/log/1c/dumps/rphost.<PID>
(gdb) info threads
(gdb) thread apply all bt

Отладочных символов платформы у вас нет, поэтому внутренние функции 1С в стеке будут без имён. Зато видны системные библиотеки: libpq (ожидание PostgreSQL), libssl, libc, libstdc++. Если падение или зависание стабильно приходится на одну стороннюю библиотеку, это уже ответ: смотрите её версию и совместимость с дистрибутивом.

Сам дамп, вывод thread apply all bt и версию платформы прикладывают к обращению в поддержку 1С или к партнёру — без этого падение rphost там не разбирают.

Автоматический сбор диагностики при зависании

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

#!/bin/bash
# /usr/local/bin/1c-diag.sh — снимок состояния рабочих процессов 1С
OUT=/var/log/1c/diag/$(date +%Y%m%d-%H%M%S)
mkdir -p "$OUT"

ps -eo pid,ppid,user,%cpu,%mem,rss,etime,args | grep -E '[r]agent|[r]mngr|[r]phost' > "$OUT/ps.txt"
ss -tnp > "$OUT/sockets.txt"
free -m > "$OUT/memory.txt"
df -h > "$OUT/disk.txt"

for PID in $(pgrep rphost); do
  timeout 10 strace -f -tt -T -p "$PID" -o "$OUT/strace.$PID" 2>/dev/null
  gdb -p "$PID" -batch -ex "thread apply all bt" > "$OUT/bt.$PID.txt" 2>&1
done

tar -czf "$OUT.tar.gz" -C "$(dirname "$OUT")" "$(basename "$OUT")" && rm -rf "$OUT"

Права и запуск:

sudo chmod 700 /usr/local/bin/1c-diag.sh
sudo /usr/local/bin/1c-diag.sh

Скрипт сознательно не снимает полный дамп каждого процесса: стеки через gdb -batch занимают килобайты, а gcore — гигабайты. Полный дамп снимайте вручную для одного подозрительного rphost.

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

Как читать результаты и где чаще всего ошибаются

Связка инструментов выглядит так: ТЖ показывает, какой вызов 1С был долгим или упал; strace — чего ждал процесс; стек из GDB — в какой библиотеке он стоит. Сводите данные по времени: момент события в ТЖ, метку в трассе, время снятия стека.

Ещё две ошибки, которые встречаются постоянно:

• ❌ Оставленный режим отладки. Включили на разбор, забыли выключить. Через месяц пользователи жалуются на «замирание» сеансов, когда кто-то из разработчиков поставил точку останова в общем модуле.
• ❌ Полный ТЖ без фильтров «на всякий случай». Раздел с логами заполняется за ночь, сервер 1С перестаёт писать временные файлы, и проблема, ради которой включали журнал, становится больше.

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