Что делать, если не запускается сервер 1С:Предприятие 8.3 на Linux CentOS с ошибкой «service failed to start»

← На главную

Внезапный сбой в работе сервера приложений 1С:Предприятие на операционной системе Linux — ситуация критическая для любого бизнеса. При этом стандартная попытка запустить службу с помощью команды service srv1cv83 start часто возвращает лаконичное и малоинформативное сообщение: Starting 1C:Enterprise 8.3 server: Error: service failed to start! FAILED. При этом в системном логе /var/log/messages может не быть абсолютно никаких записей от процессов 1С.

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

Шаг 1. Первичная диагностика и ручной запуск процессов

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

Давайте авторизуемся под этим пользователем и выполним запуск агента сервера напрямую через консоль. Для этого выполним последовательно следующие команды:


su - usr1cv8
/opt/1C/v8.3/x86_64/ragent

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


1C:Enterprise 8.3 (x86-64) (8.3.13.1865) Server Agent started. Ctrl+C to exit.
1C:Enterprise 8.3 (x86-64) (8.3.13.1865) Cluster Manager started. Ctrl+C to exit.
1C:Enterprise 8.3 (x86-64) (8.3.13.1865) Cluster Manager finished.
1C:Enterprise 8.3 (x86-64) (8.3.13.1865) Cluster Manager started. Ctrl+C to exit.
1C:Enterprise 8.3 (x86-64) (8.3.13.1865) Cluster Manager finished.
1C:Enterprise 8.3 (x86-64) (8.3.13.1865) Server Agent finished.

Этот лог наглядно показывает, что сам агент сервера ragent стартует успешно, но менеджер кластера rmngr мгновенно завершает свою работу (Cluster Manager finished). После нескольких неудачных попыток перезапустить менеджер, агент сервера также останавливается. Это сужает круг поиска: проблема кроется в настройках или целостности файлов самого кластера.

Шаг 2. Настройка технологического журнала для выявления ошибки

Чтобы понять, почему именно падает менеджер кластера, нам жизненно необходимы логи. Настроим технологический журнал 1С. Для этого создадим файл конфигурации logcfg.xml.

Обратите внимание на важный нюанс: на серверах Linux директория для записи логов должна быть доступна пользователю usr1cv8 на запись. Если указать стандартный путь /var/log/1c, запись может не пойти из-за ограничений прав доступа (SELinux или прав на саму папку). Надежнее всего настроить логирование во внутреннюю домашнюю директорию пользователя 1С, например в /home/usr1cv8/log.

Создадим файл конфигурации по пути /home/usr1cv8/.1cv8/1C/1cv8/conf/logcfg.xml со следующим содержимым:


<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="/home/usr1cv8/log" history="168">
    <event>
      <eq property="Name" value="PROC"/>
    </event>
    <event>
      <eq property="Name" value="CONN"/>
    </event>
    <event>
      <eq property="Name" value="EXCP"/>
    </event>
    <property name="all">
    </property>
  </log>
</config>

Убедимся, что целевой каталог для логов существует и права на него выданы корректно:


mkdir -p /home/usr1cv8/log
chown -R usr1cv8:grp1cv8 /home/usr1cv8/log
chmod -R 775 /home/usr1cv8/log

После повторного запуска команды /opt/1C/v8.3/x86_64/ragent в каталоге логов появятся файлы технологического журнала. Проанализируем полученные данные.

Шаг 3. Анализ логов технологического журнала

В логах процесса rmngr мы обнаружим критическое исключение (EXCP), из-за которого менеджер кластера прекращает свою работу:


17:07.908000-0,EXCP,1,process=rmngr,OSThread=28397,Exception=acea3e6e-3687-4792-8319-09c009274c9a,Descr='./src/RHostImpl.cpp(2611):
acea3e6e-3687-4792-8319-09c009274c9a: Unknown registryID, expecting 35977c5c-91d7-11ea-1d93-00e04c360255. Check the cluster registry dir.'

Физическая суть проблемы: произошла рассинхронизация уникальных идентификаторов (UUID) кластера в его конфигурационных файлах. Менеджер кластера при старте обращается к глобальному файлу настроек сервера 1С, считывает ожидаемый UUID кластера, но в локальных файлах реестра самого кластера прописан совершенно другой идентификатор. Менеджер считает структуру данных поврежденной и аварийно останавливается во избежание порчи баз данных.

Давайте сопоставим содержимое файлов реестра, чтобы увидеть эту разницу:

В главном списке кластеров сервера по пути /home/usr1cv8/.1cv8/1C/1cv8/1cv8wsrv.lst зарегистрирован кластер с UUID 35977c5c-91d7-11ea-1d93-00e04c360255:
```
{1,
{35977c5c-91d7-11ea-1d93-00e04c360255,"Local cluster",1541,"1cserver",0,0,0,0,0,0,0...
```
В то же время, в файле параметров конкретного кластера по пути /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/1CV8Clst.lst прописан абсолютно другой UUID — 3dcaa392-ab07-11ea-198f-00e04c360255:
```
{0,
{3dcaa392-ab07-11ea-198f-00e04c360255,"Local cluster",1541,"1cserver",0,0,0,0,0,0,0...
```

Эта рассинхронизация обычно происходит по нескольким причинам:

Внезапное отключение электропитания или некорректная жесткая перезагрузка сервера (hard reset), когда один из файлов успел сбросить кэш записи на диск, а второй нет.
Завершение процессов 1С жесткой командой kill -9 во время выполнения операций обновления или изменения состава кластера.
Ошибки при изменении сетевого имени сервера (hostname) или его IP-адреса, из-за чего служба пытается инициализировать параметры заново.

Способ 1. Хирургическое исправление UUID (Самый быстрый путь без потери данных)

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

Выполним процедуру ручного исправления по шагам:

Полностью остановим службу сервера 1С: service srv1cv83 stop
Обязательно убедимся, что в памяти не осталось зависших процессов rphost, rmngr или ragent, которые могут перезаписать файлы при выходе:
```
ps -fU usr1cv8
# Если процессы найдены, принудительно завершим их:
killall -9 rphost rmngr ragent
```
Откроем для редактирования файл реестра кластера /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/1CV8Clst.lst любым текстовым редактором (например, nano или vi).
Найдем неверный UUID 3dcaa392-ab07-11ea-198f-00e04c360255 и заменим его во всех вхождениях в этом файле на правильный (ожидаемый сервером) UUID из файла 1cv8wsrv.lst, то есть на 35977c5c-91d7-11ea-1d93-00e04c360255.
Если в каталоге reg_1541 присутствует резервный файл 1CV8Clsto.lst, проведем аналогичную замену UUID и в нем.
Сохраним изменения в файлах и запустим службу: service srv1cv83 start

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

Способ 2. Полное пересоздание кластера (Радикальный метод)

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

Рассмотрим этот процесс по шагам:

Остановим службу сервера приложений 1С: service srv1cv83 stop
Создадим резервную копию текущей рабочей папки кластера на случай непредвиденных обстоятельств: tar -czvf /home/usr1cv8/backup_1c_registry.tar.gz /home/usr1cv8/.1cv8/1C/1cv8/
Удалим проблемный рабочий каталог сервера 1С: rm -rf /home/usr1cv8/.1cv8/1C/1cv8/* Примечание: Если вы настраивали технологический журнал, сохраните предварительно конфигурационный файл conf/logcfg.xml, чтобы не прописывать его заново.
Запустим службу сервера приложений. При старте система обнаружит отсутствие файлов конфигурации и автоматически создаст чистый дефолтный локальный кластер с правильной структурой идентификаторов: service srv1cv83 start
Убедимся, что процессы запустились и работают в штатном режиме: service srv1cv83 status
Теперь откроем клиент «1С:Предприятие» или консоль администрирования кластеров и заново зарегистрируем наши информационные базы. Указывайте существующие имена баз данных на СУБД (PostgreSQL / MS SQL), чтобы подключить их без потери накопленной информации.

Способ 3. Точечное удаление конфигурационных файлов

Существует промежуточный вариант, когда нет необходимости удалять весь рабочий каталог (в котором могут лежать гигабайты кэша, сессий и журналов регистрации), но ручная правка UUID кажется слишком сложной. Мы можем удалить только сами конфигурационные файлы, отвечающие за перечень кластеров.

Для этого при остановленной службе сервера 1С удалим следующие файлы из папки /home/usr1cv8/.1cv8/1C/1cv8/:

1cv8wsrv.lst (файл описания списка кластеров сервера)
reg_1541/1CV8Clst.lst (файл структуры конкретного кластера)
reg_1541/1CV8Clsto.lst (резервный файл структуры, если есть)

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