Сервер 1С:Предприятия под Linux: штатный рестарт, зависший ragent и рабочие процессы

Службу сервера 1С на Linux перезапускают командой sudo systemctl restart <имя службы>. Для платформы 8.3.21 и новее имя выглядит как srv1cv8-8.3.24.1467@default (с номером вашей версии), для более старых пакетов — srv1cv83. Точное имя показывает systemctl list-units --all | grep -i srv1cv8.

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

Проверка службы и процессов до перезапуска

Сначала убедитесь, что служба действительно в проблемном состоянии, и найдите её имя. Перезапуск «на всякий случай» иногда маскирует настоящую причину: кончилось место на диске, отвалилась СУБД, закончились лицензии.

Найти службу:

systemctl list-units --all --type=service | grep -i srv1cv8

Посмотреть статус:

sudo systemctl status srv1cv8-8.3.24.1467@default

В выводе смотрите на три вещи:

• 🟢 Active: active (running) — служба работает, проблема, скорее всего, внутри кластера;
• 🔴 failed или inactive (dead) — служба упала, нужен запуск и разбор логов;
• 📋 последние строки журнала внизу вывода — часто там уже видна причина.

Затем проверьте процессы. На сервере 1С их три вида:

ps -u usr1cv8 -o pid,etime,rss,cmd | grep -E 'ragent|rmngr|rphost'
ss -tlnp | grep -E ':154[01]'

Если ragent в списке есть, а порт 1540 никто не слушает, агент завис. Если rphost занимает десятки гигабайт памяти (rss в килобайтах), проблема в рабочем процессе, а не в службе целиком.

Ещё две быстрые проверки перед рестартом:

df -h /home/usr1cv8      # каталог кластера и журналов
free -h                  # память и своп

Заполненный диск — частая причина «зависания» сервера. Перезапуск его не лечит: служба поднимется и снова встанет.

Штатный перезапуск через systemctl

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

Платформа 8.3.21 и новее

sudo systemctl restart srv1cv8-8.3.24.1467@default
sudo systemctl status srv1cv8-8.3.24.1467@default

Если нужно сначала остановить, что-то поправить и потом запустить:

sudo systemctl stop srv1cv8-8.3.24.1467@default
# ... ваши действия ...
sudo systemctl start srv1cv8-8.3.24.1467@default

Суффикс @default — имя экземпляра. Если на сервере несколько экземпляров (например, разные порты для разных версий), у каждого своё имя после @.

Платформа до 8.3.21

Старые пакеты ставят init-скрипт. Systemd подхватывает его автоматически, поэтому работают обе формы:

sudo systemctl restart srv1cv83
sudo /etc/init.d/srv1cv83 restart

Как понять, что рестарт прошёл успешно

1. systemctl status показывает active (running).
2. В ps снова есть ragent, rmngr и хотя бы один rphost.
3. Порты 1540 и 1541 слушаются (ss -tlnp).
4. Пользователь открывает базу с клиента.

💡 После обновления платформы частая ошибка — перезапускать старую службу. Новый установщик не трогает юнит предыдущей версии: он остаётся включённым. Отключите старый (systemctl disable --now srv1cv8-<старая версия>@default) и включите новый, иначе после ребута поднимется не та версия или обе подерутся за порт 1540.

Рабочие процессы кластера: точечный рестарт без остановки службы

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

Запуск ras, если он ещё не работает :

sudo -u usr1cv8 /opt/1cv8/x86_64/8.3.24.1467/ras cluster --daemon

По умолчанию ras слушает порт 1545 и подключается к агенту на localhost:1540.

Дальше — получить идентификатор кластера и список процессов:

RAC=/opt/1cv8/x86_64/8.3.24.1467/rac
$RAC cluster list
$RAC process list --cluster=<uuid кластера>

В выводе process list у каждого процесса есть pid, объём памяти и признак активности. Найдите процесс-нарушитель по памяти или по времени работы.

Если на кластере задан администратор, к командам добавьте --cluster-user=<имя> --cluster-pwd=<пароль>.

Завершить сеансы перед действием

Посмотреть, кто работает:

$RAC session list --cluster=<uuid кластера>

Завершить конкретный сеанс:

$RAC session terminate --cluster=<uuid кластера> --session=<uuid сеанса>

Перезапустить один rphost

Самый прямой способ — завершить процесс по pid из вывода rac process list:

sudo kill <pid>

Кластер сам поднимет новый рабочий процесс взамен. Все сеансы, которые обслуживал этот rphost, оборвутся с потерей несохранённых данных, поэтому сначала посмотрите список сеансов и предупредите людей.

Чтобы процессы перезапускались сами

В свойствах кластера (консоль администрирования серверов 1С или rac cluster update) есть параметры, которые заставляют кластер мягко менять рабочие процессы:

• ⏱ интервал перезапуска — процесс плавно заменяется новым через заданное число секунд, сеансы переносятся;
• 📈 допустимый объём памяти рабочих процессов и интервал его превышения — кластер перезапускает процесс, который вышел за лимит.

Точные имена параметров для rac смотрите в rac help cluster: они различаются написанием от версии к версии. Плавная замена бережнее ручного kill, потому что сеансы переезжают на новый процесс.

Если служба зависла и не останавливается

Бывает, что systemctl stop висит минуту и больше, а ragent остаётся в списке процессов. Порядок действий — от мягкого к жёсткому.

1. Подождите 1–2 минуты. Агент при остановке сначала гасит рабочие процессы, на больших кластерах это не мгновенно.
2. Посмотрите, какие процессы ещё живы:

   ps -u usr1cv8 -o pid,etime,cmd
   

3. Отправьте им обычный сигнал завершения:

   sudo pkill -TERM -u usr1cv8 -f 'ragent|rmngr|rphost'
   

4. Если через 30 секунд процессы на месте — принудительно:

   sudo pkill -KILL -u usr1cv8 -f 'ragent|rmngr|rphost'
   

5. Сбросьте состояние юнита и запустите службу:

   sudo systemctl reset-failed srv1cv8-8.3.24.1467@default
   sudo systemctl start srv1cv8-8.3.24.1467@default
   

Очистка сеансовых данных

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

1. Остановите службу (сеансы оборвутся).
2. Сделайте копию каталога кластера: cp -a /home/usr1cv8/.1cv8/1C/1cv8 /root/1cv8-backup-$(date +%F).
3. В каталоге reg_1541 удалите только папки с именами, которые начинаются на snccntx.
4. Запустите службу.

Не удаляйте файл 1CV8Clst.lst и папки с идентификаторами баз — в них реестр кластера: список информационных баз, администраторы, настройки. Без них кластер придётся настраивать заново.

Путь /home/usr1cv8/.1cv8/1C/1cv8 — значение по умолчанию. Если при установке задавали другой каталог данных, он указан в параметрах службы (см. раздел про автозапуск).

Где искать причину: журналы systemd и технологический журнал

Перезапуск снимает симптом. Чтобы понять, почему сервер встал, смотрите журналы.

Журнал systemd

sudo journalctl -u srv1cv8-8.3.24.1467@default --since "1 hour ago"
sudo journalctl -u srv1cv8-8.3.24.1467@default -f      # в реальном времени

Здесь видны ошибки старта: занятый порт, нехватка прав, отсутствие библиотек после обновления ОС.

Системные сообщения ядра

Если процессы исчезли сами, проверьте, не убил ли их OOM killer:

sudo journalctl -k | grep -iE 'out of memory|killed process'

Строка с rphost или rmngr означает, что серверу не хватает памяти. Лечится лимитами памяти в кластере, добавлением свопа или ОЗУ, а не рестартами.

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

Подробную картину даёт технологический журнал 1С. Он включается файлом logcfg.xml в каталоге conf платформы (для 8.3.21+ это /opt/1cv8/conf/). Минимальная настройка для поиска аварий:

<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>
</config>

Каталог из location создайте заранее и дайте права пользователю usr1cv8. Параметр history — сколько часов хранить файлы. События EXCP — исключения, по ним видно, что происходило перед падением процесса.

💡 Не оставляйте журнал с широким набором событий надолго: он быстро занимает гигабайты и сам может положить сервер, заполнив диск.

Дамп при падении

Если rphost падает аварийно, полезен дамп для разбора. Для этого в logcfg.xml добавляют элемент <dump> с каталогом для файлов. Дамп пригодится, если будете обращаться в поддержку или к разработчику конфигурации.

Автозапуск службы и плановый перезапуск

Включить автозагрузку

Чтобы сервер 1С поднимался после перезагрузки Linux:

sudo systemctl enable srv1cv8-8.3.24.1467@default
systemctl is-enabled srv1cv8-8.3.24.1467@default

Для платформы 8.3.21+ юнит сначала подключают к systemd из каталога установки (если этого не сделал установщик):

sudo systemctl link /opt/1cv8/x86_64/8.3.24.1467/srv1cv8-8.3.24.1467@.service
sudo systemctl enable --now srv1cv8-8.3.24.1467@default

Изменить порты и каталог данных

Не правьте файл юнита в /opt/1cv8 напрямую: обновление платформы его перезапишет. Используйте override:

systemctl cat srv1cv8-8.3.24.1467@default     # посмотреть текущие переменные
sudo systemctl edit srv1cv8-8.3.24.1467@default

В открывшемся редакторе в секции [Service] переопределите нужные строки Environment= (имена переменных берите из вывода systemctl cat). Затем sudo systemctl daemon-reload и перезапуск службы.

Для старых пакетов те же параметры — порт, диапазон, каталог кластера — задаются в /etc/default/srv1cv83 или /etc/sysconfig/srv1cv83.

Автоматический подъём после падения

В тот же override можно добавить:

[Service]
Restart=on-failure
RestartSec=30

Systemd перезапустит службу, если процесс завершился с ошибкой. Это страховка от редких падений, а не лечение: если служба падает регулярно, ищите причину в журналах.

Ночной перезапуск по расписанию

Некоторые администраторы перезапускают сервер раз в сутки, чтобы освободить память. Удобнее всего через cron пользователя root:

# crontab -e
30 3 * * * /usr/bin/systemctl restart srv1cv8-8.3.24.1467@default

Перед этим убедитесь, что в 03:30 не работают регламентные задания: обмены, резервное копирование баз, закрытие месяца. Рестарт оборвёт их посреди выполнения. Если процессы растут по памяти, бережнее настроить интервал перезапуска рабочих процессов в кластере — эффект тот же, но без разрыва сеансов.

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