Администрирование серверов «1С:Предприятие» на операционных системах семейства Linux (таких как CentOS, RedHat, Ubuntu) имеет ряд специфических особенностей. В отличие от Windows, где большинство ошибок логируется в стандартном просмотре событий, на Linux администратору приходится глубже погружаться в текстовые конфигурационные файлы, системные логи и настройки прав доступа. Рано или поздно любой администратор может столкнуться с ситуацией, когда стабильно работавший сервер 1С внезапно перестает запускаться, выдавая лаконичную и малоинформативную ошибку Error: service failed to start! FAILED.
В этой статье мы подробно разберем, почему возникает подобный сбой, как правильно настроить логирование для выявления причин, проанализируем структуру конфигурационных файлов сервера 1С и рассмотрим два метода решения проблемы: радикальный (с полной очисткой настроек) и гуманный (с сохранением всех зарегистрированных информационных баз и настроек кластера).
Рассмотрим типичную ситуацию. При попытке запустить службу сервера 1С в консоли Linux (в данном примере CentOS) с помощью стандартной команды:
service srv1cv83 start
Мы наблюдаем следующее сообщение об ошибке:
Starting 1C:Enterprise 8.3 server: Error: service failed to start! FAILED
При этом в системных сообщениях ОС (файл /var/log/messages) нет никаких записей, указывающих на проблемы с процессами 1С. Для того чтобы понять, что происходит со службой, выполним команду проверки статуса:
service srv1cv83 status
Проанализируем динамику поведения службы. Сразу после попытки запуска мы можем увидеть обнадеживающий статус:
1C:Enterprise 8.3 server status:
Init script: STARTED.
Ragent: RUNNING.
Однако спустя примерно минуту повторный запрос статуса показывает, что служба аварийно завершила работу:
1C:Enterprise 8.3 server status:
Init script: STARTED.
Ragent: NOT RUNNING.
Попробуем запустить агент сервера ragent вручную от имени пользователя usr1cv8, под которым обычно функционирует сервер 1С. Это позволит нам увидеть вывод ошибок напрямую в консоль:
su - usr1cv8
/opt/1C/v8.3/x86_64/ragent
В консоли мы увидим бесконечный цикл перезапуска менеджера кластера rmngr:
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 мгновенно завершает свою работу с ошибкой. После нескольких неудачных попыток запустить менеджер кластера падает и сам агент. Чтобы выяснить истинную причину падения rmngr, нам необходимо настроить Технологический журнал (ТЖ) 1С.
Для включения логирования нам необходимо создать файл конфигурации технологического журнала logcfg.xml. Он должен располагаться в каталоге /home/usr1cv8/.1cv8/1C/1cv8/conf/ (путь может незначительно отличаться в зависимости от домашней директории пользователя usr1cv8).
Создадим или отредактируем этот файл, добавив в него следующие настройки для логирования событий работы процессов rmngr и критических исключений:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-journal">
<log location="/home/usr1cv8/log" history="4">
<event filter="">
<eq property="Name" value="EXCP"/>
</event>
<event filter="">
<eq property="Name" value="PROC"/>
</event>
<event filter="">
<eq property="Name" value="CONN"/>
</event>
<property name="All"/>
</log>
</config>
Важный нюанс для операционных систем на базе RedHat/CentOS: часто администраторы указывают путь для вывода логов в системные папки, например /var/log/1c, предварительно выдав права пользователю usr1cv8 с помощью команд chown и chmod. Однако логи туда все равно не пишутся. Причина кроется в подсистеме безопасности SELinux, которая по умолчанию активна в CentOS.
Политики SELinux запрещают процессам, запущенным от имени обычных пользователей (не root), писать в системные каталоги уровня /var/log. Чтобы обойти это ограничение без отключения SELinux, мы рекомендуем указывать в качестве пути логирования подкаталоги внутри домашней папки пользователя 1С, например: /home/usr1cv8/log. В домашнем каталоге у пользователя usr1cv8 есть полные права, и SELinux не блокирует операции записи.
Не забудьте создать эту папку и выдать на нее права (если они по какой-то причине отсутствуют):
mkdir -p /home/usr1cv8/log
chown -R usr1cv8:grp1cv8 /home/usr1cv8/log
После корректной настройки файла logcfg.xml и перезапуска службы в папке /home/usr1cv8/log начнут создаваться файлы логов. Открыв их, мы обнаружим критическую ошибку, из-за которой падает менеджер кластера:
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.'
Проанализируем суть этой ошибки. Менеджер кластера rmngr сообщает нам: Unknown registryID, expecting 35977c5c-91d7-11ea-1d93-00e04c360255. Это означает, что возникла рассинхронизация (несоответствие) уникальных идентификаторов (GUID) кластера в конфигурационных файлах реестра сервера 1С.
Разберемся, где именно хранятся эти идентификаторы и как устроена структура файлов конфигурации 1С на Linux. Перейдем в рабочую папку сервера 1С: /home/usr1cv8/.1cv8/1C/1cv8/. Здесь находятся два ключевых конфигурационных файла:
1cv8wsrv.lst. Этот файл содержит список всех созданных на данном физическом сервере кластеров. Открыв его, мы увидим описание локального кластера:
{
{1, {35977c5c-91d7-11ea-1d93-00e04c360255,"Local cluster",1541,"1cserver",0,0,0,0,0,0,0,
{1, {"1cserver",1541} },0,0,0}
}, {0},0,1
}
35977c5c-91d7-11ea-1d93-00e04c360255. Именно этот ID агент сервера передает менеджеру кластера при старте.
1CV8Clst.lst. Он располагается в подпапке соответствующего порта, по умолчанию это reg_1541: /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/1CV8Clst.lst. Этот файл содержит информацию обо всех зарегистрированных в данном кластере информационных базах, пользователях и процессах. Его содержимое выглядит следующим образом:
{0, {3dcaa392-ab07-11ea-198f-00e04c360255,"Local cluster",1541,"1cserver",0,0,0,0,0,0,0,
{1, {"1cserver",1541} },0,0,0},
...
}
3dcaa392-ab07-11ea-198f-00e04c360255.
Почему происходит сбой? При старте службы агент ragent считывает файл общего реестра 1cv8wsrv.lst, находит там ID кластера 35977c5c... и запускает процесс rmngr, указывая ему работать с этим ID. Менеджер кластера обращается к папке reg_1541, открывает локальный реестр 1CV8Clst.lst и обнаруживает там ID 3dcaa392.... Видя несовпадение идентификаторов, rmngr из соображений безопасности немедленно прекращает работу, чтобы избежать перезаписи или повреждения данных.
Такая ситуация чаще всего происходит из-за аварийного отключения питания сервера, некорректного восстановления файлов из резервной копии (когда восстановили только папку reg_1541, но забыли восстановить файл 1cv8wsrv.lst) или при изменении сетевого имени сервера (hostname).
Этот метод применил автор темы на форуме. Он заключается в полном удалении настроек сервера и создании нового чистого кластера «с нуля».
Рассмотрим по шагам данный алгоритм:
service srv1cv83 stop
conf):
mv /home/usr1cv8/.1cv8/1C/1cv8 /home/usr1cv8/.1cv8/1C/1cv8_backup
Или, если вы уверены в своих действиях, удалите файлы напрямую:
rm -rf /home/usr1cv8/.1cv8/1C/1cv8/*
service srv1cv83 start
При первом запуске сервер 1С обнаружит отсутствие конфигурационных файлов и автоматически сгенерирует структуру папок заново, создав новый чистый кластер с новыми согласованными GUID. Менеджер кластера запустится успешно.
Недостатки метода: Если на вашем сервере было зарегистрировано большое количество информационных баз (десятки или сотни), этот метод доставит много хлопот. Вам придется вручную через консоль администрирования или программно заново регистрировать каждую базу, указывать параметры подключения к СУБД, настраивать параметры рабочих процессов, заново создавать администраторов кластера и т.д.
Чтобы избежать рутинной работы по повторному добавлению баз и сохранить все настройки кластера, мы можем вручную синхронизировать идентификаторы в конфигурационных файлах. Этот метод полностью безопасен при соблюдении аккуратности.
Выполним процедуру по шагам:
service srv1cv83 stop
cp /home/usr1cv8/.1cv8/1C/1cv8/1cv8wsrv.lst /home/usr1cv8/.1cv8/1C/1cv8/1cv8wsrv.lst.bak
cp /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/1CV8Clst.lst /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/1CV8Clst.lst.bak
1cv8wsrv.lst с помощью любого текстового редактора (например, nano или vi):
nano /home/usr1cv8/.1cv8/1C/1cv8/1cv8wsrv.lst
35977c5c-91d7-11ea-1d93-00e04c360255) и замените его на актуальный идентификатор из файла реестра кластера 1CV8Clst.lst (в нашем примере это 3dcaa392-ab07-11ea-198f-00e04c360255). Будьте внимательны: не удаляйте кавычки, запятые и фигурные скобки, измените только саму строку GUID.nano для этого нажмите Ctrl+O, затем Enter для сохранения и Ctrl+X для выхода).service srv1cv83 start
service srv1cv83 status
Теперь менеджер кластера rmngr прочитает обновленный файл общего реестра, увидит согласованный идентификатор, соответствующий файлу 1CV8Clst.lst в директории reg_1541, и успешно продолжит работу. Все ваши информационные базы, настройки регламентных заданий и профили безопасности останутся в полной сохранности!
Разберем еще несколько критически важных моментов, которые влияют на стабильность запуска сервера 1С под управлением ОС Linux.
Разрешение имени хоста (DNS и Hosts)
В логах технологического журнала мы можем заметить строку:
17:05.682001-0,CONN,0,process=rmngr,OSThread=28404,Txt='addrBelongsToThisComputer2, address=1cserver, result=true'
Эта запись говорит о том, что процесс 1С проверяет, принадлежит ли сетевое имя 1cserver локальному компьютеру. Платформа 1С на Linux крайне чувствительна к правильному разрешению имен хостов. Если сервер не сможет сопоставить свое сетевое имя с локальным IP-адресом, инициализация сокетов завершится ошибкой, и служба упадет еще до проверки реестров.
Обязательно проверяйте файл /etc/hosts. В нем должна присутствовать запись, связывающая имя вашего сервера с локальной петлей 127.0.0.1 или реальным статическим IP-адресом сетевой карты:
127.0.0.1 localhost localhost.localdomain 1cserver
# или
192.168.1.10 1cserver
Резервное копирование настроек кластера
Для предотвращения подобных сбоев в будущем возьмите за правило регулярно делать резервное копирование папки конфигурации 1С. Достаточно добавить в планировщик cron простую задачу, которая будет архивировать файлы реестров раз в сутки:
tar -czf /backup/1c_cluster_$(date +%F).tar.gz /home/usr1cv8/.1cv8/1C/1cv8/*.lst /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/*.lst
Имея под рукой согласованную копию файлов 1cv8wsrv.lst и 1CV8Clst.lst, вы сможете восстановить работоспособность сервера за считанные секунды в случае любого аппаратного или программного сбоя.