Почему не стартует сервер 1С (rphost, rmngr) на Ubuntu Linux и как это исправить?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Рассмотрим достаточно специфичную, но неприятную ситуацию: вы установили сервер 1С:Предприятие на ОС Ubuntu Linux, служба агента сервера (ragent) вроде бы работает, но основные рабочие процессы — rphost (рабочий процесс) и rmngr (менеджер кластера) — не запускаются. При этом стандартная проверка не выявляет очевидных проблем: права на каталоги с бинарными файлами выданы, порты свободны, а в системных логах пусто. В этой статье мы разберем по шагам, как диагностировать и решить эту проблему, основываясь на реальном примере.

Исходные данные проблемы: не стартуют процессы сервера 1С версии 8.3.23.1912 (x32) на операционной системе Ubuntu 20.04 (x86_64). Давайте проанализируем ситуацию и найдем решение.

Основная причина: ошибка в конкретной версии платформы 1С

Как ни странно, после долгих поисков и проверок часто выясняется, что проблема кроется не в настройках сервера или операционной системы, а в самой сборке платформы 1С. В рассматриваемом случае именно так и произошло.

Платформа 1С версии 8.3.23.1912 содержит зарегистрированную ошибку, которая при определенных условиях приводит к невозможности запуска серверных компонент на Linux. Это подтверждается официальным баг-трекером компании 1С. Проблема может проявляться не на всех конфигурациях оборудования и ОС, что делает ее диагностику особенно сложной.

Самое простое и эффективное решение в данном случае — сменить версию платформы.

  1. Выберите другую, более стабильную версию. Рекомендуется использовать либо более новую версию, в которой ошибка уже исправлена, либо предыдущую, проверенную временем.
  2. Полностью удалите проблемную версию 8.3.23.1912 с сервера.
  3. Установите выбранную стабильную версию платформы.

В большинстве случаев после смены версии сервер успешно стартует без каких-либо дополнительных манипуляций. Это подчеркивает важность проверки списка известных ошибок для конкретного релиза перед тем, как тратить часы на поиск проблемы в конфигурации.

Дополнительная сложность: установка 32-битного сервера на 64-битную ОС Linux

Даже если бы проблема была не в баге платформы, сама по себе задача установки 32-битного приложения на 64-битную операционную систему требует особого внимания. 64-битные системы по умолчанию не содержат полного набора библиотек, необходимых для работы 32-битных программ. Их нужно установить вручную. Разберем этот процесс по шагам.

Шаг 1: Подключение 32-битной архитектуры (i386)

Первое, что необходимо сделать, — это сообщить менеджеру пакетов вашей системы (apt), что вы собираетесь устанавливать пакеты для другой архитектуры. Для этого выполним следующие команды в терминале:


sudo dpkg --add-architecture i386
sudo apt-get update

Первая команда добавляет i386 в список поддерживаемых архитектур. Вторая — обновляет списки пакетов, чтобы система знала о наличии 32-битных версий в репозиториях.

Шаг 2: Установка необходимых 32-битных библиотек

Теперь нужно установить сами библиотеки, от которых зависит работа сервера 1С. Даже если вы используете современный единый инсталлятор .run от 1С, он может не справиться с установкой всех зависимостей. Поэтому лучше сделать это принудительно. Изучая подобные особенности настройки Astra Linux с установкой зависимостей, можно заметить, что ручное управление пакетами часто оказывается надежнее автоматики.

Вот базовый набор пакетов, которые часто требуются:


sudo apt-get install imagemagick:i386 unixodbc:i386 libgsf-bin:i386 ttf-mscorefonts-installer

Давайте разберем, за что отвечает каждый компонент:

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

Комплексная диагностика: когда причина неясна

Если смена версии не помогла или вы хотите досконально разобраться в причинах, необходимо провести полную диагностику системы. Чтобы упростить оперативное управление процессами в ходе тестов, можно использовать WEB приложение для управления сеансами 1С сервера, которое позволяет визуально контролировать состояние rphost — для этого подойдет веб-приложение для управления сеансами 1С.

Проверка прав доступа

Частая ошибка — выдать права только на каталог с бинарными файлами (/opt/1C/v8.3/...). Сервер 1С также активно использует домашний каталог пользователя, от имени которого он запущен (по умолчанию это usr1cv8).

  1. Убедитесь, что пользователь usr1cv8 существует и входит в группу grp1cv8.
  2. Проверьте, что у этого пользователя есть права на чтение и запись в свой домашний каталог (обычно /home/usr1cv8/).
  3. Особое внимание уделите подкаталогу /home/usr1cv8/.1cv8/. Именно здесь сервер хранит файлы состояния кластера, кэш и другие служебные данные. Если прав на запись в этот каталог не будет, процессы не смогут стартовать.

Команда для рекурсивного назначения прав:


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

Проверка сетевых портов

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

Проверить, свободны ли порты, можно с помощью команды ss или netstat:


sudo ss -tulpn | grep -E "1540|1541|156"

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

Очистка кэша сервера

Иногда причиной сбоя могут быть поврежденные файлы состояния кластера. В этом случае помогает полная очистка кэша. Также, если вы настраиваете чистый сервер для тестов, вам может пригодиться установка комьюнити-лицензии разработчика на сервер 1С по рецептам от Капитана. Действуйте осторожно при очистке кэша, так как будут удалены все настройки кластера.

  1. Остановите службу агента сервера: sudo systemctl stop srv1cv8-8.3.23.1912@default.service (укажите вашу версию).
  2. Удалите содержимое рабочего каталога кластера. Обычно это файлы в /home/usr1cv8/.1cv8/1C/1cv8/. Например, файл 1CV8Clst.lst.
  3. Запустите службу агента сервера обратно: sudo systemctl start srv1cv8-8.3.23.1912@default.service.

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

Глубокий анализ: используем Технологический журнал 1С

Если системные логи пусты, а сервер все равно не стартует, на помощь приходит мощнейший инструмент диагностики — Технологический журнал (ТЖ) (поможет инструмент для анализа данных технологического журнала). Он позволяет записывать все внутренние события платформы 1С, даже те, которые происходят до полноценного запуска процессов. Для удобства последующей обработки данных вы можете использовать конвертер технологического журнала в новый формат JSON, а чтобы отчеты не раздувались, примените способ убирать лишние переносы строк в событиях журнала.

Чтобы его включить, выполним следующие действия:

  1. Создаем каталог для логов. Логи могут занимать много места, поэтому лучше выделить для них отдельную папку.
    
    sudo mkdir -p /var/log/1c/
    sudo chown usr1cv8:grp1cv8 /var/log/1c/
    
  2. Создаем конфигурационный файл logcfg.xml. Этот файл должен находиться в каталоге conf вашей версии платформы. Например, для 32-битной версии это будет /opt/1C/v8.3/i386/conf/.
    
    sudo nano /opt/1C/v8.3/i386/conf/logcfg.xml
    
  3. Наполняем файл настройками. Вставим в него простую конфигурацию для отслеживания запуска сервера и возможных исключений.
    
    <?xml version="1.0" encoding="UTF-8"?>
    <config xmlns="http://v8.1c.ru/v8/tech-log">
      <log location="/var/log/1c" history="4">
        <event>
          <eq property="name" value="PROC"/>
        </event>
        <event>
          <eq property="name" value="SRV"/>
        </event>
        <event>
          <eq property="name" value="EXCP"/>
        </event>
        <property name="all"/>
      </log>
    </config>
    
  4. Перезапускаем сервер.
    
    sudo systemctl restart srv1cv8-8.3.23.1912@default.service
    

Теперь в каталоге /var/log/1c начнут появляться файлы логов. Внимательно изучите их. Часто именно там можно найти точное сообщение об ошибке: нехватка какой-либо библиотеки или проблема с доступом к файлу. После успешного запуска сервера не забудьте настроить регулярное обслуживание баз данных 1C на Postgresql, чтобы обеспечить стабильную работу всей системы.

← На главную