Почему не запускается сервер 1С на Ubuntu Server и как его настроить

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

При развертывании сервера 1С:Предприятие на операционной системе Ubuntu Server системные администраторы часто сталкиваются со ситуацией, когда служба srv1cv83 стартует без явных ошибок в консоли, однако фоновый процесс агента ragent не появляется в списке запущенных или моментально завершает работу. Разберем по шагам причины такого поведения, проанализируем сбои и настроим корректную работу всех компонентов кластера.

Основные причины падения процессов сервера 1С в Linux

Проанализировав диагностические данные и логи технологического журнала, выделяем основные факторы, препятствующие запуску служб 1С:

  1. Некорректная работа драйверов аппаратных ключей защиты HASP: отсутствие необходимых 32-битных библиотек в 64-битной системе вызывает сбой службы haspd и остановку агента 1С.
  2. Ошибки прав доступа к каталогам кластера: если у пользователя usr1cv8 или группы grp1cv8 отсутствуют права на чтение и запись в каталоге /home/usr1cv8/.1cv8/ или рабочем каталоге установки, процессы падают с ошибкой вида core::FileException.
  3. Недостаток оперативной памяти: 64-битный сервер 1С требователен к ресурсам. При объеме ОЗУ менее 2 Гб система или сам агент могут завершать процессы сигналом 15 (SIGTERM) или сигналом 6 (SIGABRT).
  4. Проблемы с сетевыми именами и IPv6: неумение сервера сопоставить собственное имя hostname с локальным IP-адресом приводит к таймауту соединения между агентом ragent и менеджером кластера rmngr на порту 1541.

Шаг 1. Настройка драйверов ключей HASP и 32-битной архитектуры

Даже если на сервере установлена 64-битная версия Ubuntu и 64-битный сервер 1С, драйверу защиты HASP (aksusbd / haspd) требуется поддержка 32-битной архитектуры и соответствующие библиотеки. Без них служба защиты не сможет обнаружить ключ или запустить необходимый демон.

Выполним последовательно добавление 32-битной архитектуры и установку необходимых пакетов:


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

После установки 32-битных библиотек перезапустим сервис драйвера и проверим его детальный статус:


sudo service haspd restart
sudo service haspd status

Убедимся, что статус службы активен, а демон aksusbd успешно запущен в системе.

Шаг 2. Разрешение сетевых имен и отключение IPv6

Процесс агента ragent общается с менеджером кластера rmngr по протоколу TCP через порт 1541. Если при попытке установить соединение возникает ошибка вида NetDataExchangeException с текстом Connection timed out, проанализируем файл /etc/hosts.

Проверим, чтобы имя сервера явно сопоставлялось с его статическим сетевым IP-адресом, а не только с loopback-интерфейсом. Откроем файл конфигурации сети:

sudo nano /etc/hosts

Приведем содержимое к правильному виду, закомментировав лишние привязки IPv6 для предотвращения сетевых задержек:


127.0.0.1       localhost
192.168.1.6     webforma

# ::1     localhost ip6-localhost ip6-loopback

Убедимся, что команда ping webforma успешно отправляет пакеты на рабочий IP-адрес сервера.

Шаг 3. Проверка и исправление прав доступа

Агент 1С запускается от имени системного пользователя usr1cv8, входящего в группу grp1cv8. Если служебные файлы создавались от имени пользователя root, процесс 1С не сможет обновить файлы конфигурации кластера (например, 1cv8wsrv.lst).

Выясним и восстановим правильные права на домашнюю директорию пользователя 1С и каталог установленной платформы:


sudo chown -R usr1cv8:grp1cv8 /home/usr1cv8
sudo chmod -R 775 /home/usr1cv8

sudo chown -R usr1cv8:grp1cv8 /opt/1C/v8.3/x86_64
sudo chmod -R 775 /opt/1C/v8.3/x86_64

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


sudo service srv1cv83 stop
sudo mv /home/usr1cv8/.1cv8 /home/usr1cv8/.1cv8_backup
sudo service srv1cv83 start

Шаг 4. Ручной запуск агента и анализ технологического журнала

Чтобы увидеть детализированный вывод ошибок напрямую в консоли, минуя скрипты демонизации, запустим агент сервера вручную от имени пользователя usr1cv8 или root в режиме отладки:

/opt/1C/v8.3/x86_64/ragent -debug

Если процесс моментально завершается с сообщением terminate called after throwing an instance of 'core::FileException' или Aborted (core dumped), это однозначно указывает на отсутствие прав на запись в служебные файлы или нехватку системных ресурсов.

Для подробного анализа настроим технологический журнал. Создадим файл logcfg.xml в каталоге /opt/1C/v8.3/x86_64/conf/:


<config xmlns="http://v8.1c.ru/8.2/virtual-resource-system">
    <log dir="/home/usr1cv8/1clogs" history="24">
        <event>
            <eq property="name" value="EXCP"/>
        </event>
        <event>
            <eq property="name" value="PROC"/>
        </event>
        <property name="all"/>
    </log>
</config>

Убедимся, что на папку /home/usr1cv8/1clogs также назначены права для пользователя usr1cv8. В логах событий EXCP обратим внимание на следующие записи:

Шаг 5. Проверка сетевых портов и первоначальное создание кластера

После корректной настройки прав и ключей защиты запустим службу 1С и проверим состояние прослушиваемых портов с помощью утилиты netstat:


sudo service srv1cv83 start
sudo netstat -tlnp | grep 1540

При успешном запуске агента порт 1540 перейдет в состояние LISTEN и будет занят процессом ragent:

tcp 0 0 0.0.0.0:1540 0.0.0.0:* LISTEN 2938/ragent

Обратим внимание, что порт 1541 (менеджер кластера rmngr) появится в списке listening-портов только после того, как к агенту впервые подключатся для создания рабочего кластера. На Linux-серверах отсутствует оснастка «Администрирование серверов 1С», поэтому первое подключение и создание локального кластера необходимо выполнять с утилиты администрирования на Windows-ПК или с помощью консольной утилиты rac, обращаясь по IP-адресу сервера и порту 1540.

← На главную