← На главную

При разворачивании или перезапуске сервера 1С:Предприятия в операционных системах семейства Linux (Ubuntu, Debian, CentOS) в связке с СУБД PostgreSQL системные администраторы часто сталкиваются с ошибкой: «Ошибка при создании информационной базы. Сервер 1С:Предприятия не обнаружен. Не запущен ни один рабочий процесс. Соединение с информационной базой невозможно». Разберем по шагам, почему возникает эта проблема и как полностью восстановить работоспособность кластера 1С.

Причина 1. Зависшие pid-файлы и повреждение конфигурационных файлов кластера

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

Кроме того, повреждение файлов настроек кластера (файлы с расширением .lst) блокирует стартовый запуск рабочих процессов rphost.

Рассмотри последовательность действий для очистки зависших файлов и сброса кэша кластера:

1. Остановим службу сервера 1С:Предприятия: sudo service srv1cv83 stop
2. Удалим файл PID, мешающий повторному старту службы: sudo rm -f /var/run/srv1cv83.pid
3. Переместим или удалим служебный каталог профиля пользователя 1С (обычно usr1cv8 или usr1cv81), в котором хранятся настройки кластера: sudo mv /home/usr1cv8/.1cv8 /tmp/1cv8_backup
4. Запустим службу сервера 1С заново: sudo service srv1cv83 start

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

Причина 2. Ошибки прав доступа и настроек оболочки пользователя usr1cv8

Служба сервера 1С запускается от имени специального системного пользователя (по умолчанию usr1cv8). Если у этого пользователя отсутствуют права на запись в каталог /var/run/, домашнюю директорию или системные каталоги, процессы rphost или ragent завершатся со сбоем.

Выясним, как проверить и исправить права доступа:

1. Убедимся, что домашняя директория пользователя установлена корректно (например, /home/usr1cv8) и пользователь является её владельцем: sudo chown -R usr1cv8:grp1cv8 /home/usr1cv8
2. Установим корректный командный интерпретатор для пользователя usr1cv8 в файле /etc/passwd. В некоторых дистрибутивах Linux по умолчанию назначена оболочка /bin/sh, что вызывает проблемы при автозапуске скриптов. Изменим оболочку на /bin/bash: sudo usermod -s /bin/bash usr1cv8
3. В стартовом скрипте /etc/init.d/srv1cv83 первой строкой обязательно должен быть указан явный интерпретатор: #!/bin/bash.

Причина 3. Блокировка сетевых портов и проблемы с резолвом имен

Сервер 1С:Предприятия использует для связи агента (порт 1540), менеджера кластера (порт 1541) и динамический диапазон портов для рабочих процессов rphost (по умолчанию 1560–1591). Если сетевой экран (брандмауэр) блокирует этот диапазон, клиентские подключения не смогут достучаться до рабочего процесса.

Проанализируем сетевые настройки и имя хоста:

1. Проверим прослушиваемые порты в системе: ss -tulpn | grep 1c
2. Настроим правила сетевого экрана, открыв весь диапазон портов 1540–1591.
3. Убедимся, что имя сервера корректно сопоставляется с IP-адресом в файле /etc/hosts. Важно, чтобы короткое имя машины и полное доменное имя (FQDN) резолвились на один и тот же IP-адрес:
   Скопировать код

   
   192.168.1.10 linuxserver linuxserver.domain.local
   127.0.0.1 localhost linuxserver
   

Причина 4. Ошибки системных локалей PostgreSQL (lc_messages)

Иногда при создании информационной базы на сервере Linux появляется сопутствующая ошибка СУБД: «неверное значение параметра "lc_messages": "en_US"» или ошибки, связанные с кодировкой UTF-8.

Решим эту проблему, сгенерировав необходимые локали в Linux:

1. Сгенерируем необходимые языковые локали в операционной системе:
   Скопировать код

   
   sudo locale-gen en_US.UTF-8
   sudo locale-gen ru_RU.UTF-8
   sudo locale-gen en_US.ISO-8859-1
   sudo dpkg-reconfigure locales
   

2. Перезапустим службу СУБД PostgreSQL и проверим настройки в файле pg_hba.conf для разрешенных сетевых подключений.

Причина 5. Ограничения операционной системы и системные зависимости

В современных дистрибутивах Linux рабочие процессы rphost могут экстренно завершаться из-за лимитов ОС или особенностей работы менеджера systemd:

1. Завершение процессов через Systemd: В файле /etc/systemd/logind.conf параметр KillUserProcesses=yes может приводить к принудительному завершению процессов фонового пользователя usr1cv8 при выходе из сессии. Рекомендуется установить: KillUserProcesses=no и перезапустить службу systemd-logind.
2. Системные лимиты (ulimit): Добавим в файл /etc/security/limits.conf повышенные лимиты на открытые файлы и количество процессов для пользователя usr1cv8:
   Скопировать код

   
   usr1cv8 soft nofile 65536
   usr1cv8 hard nofile 65536
   usr1cv8 soft nproc 131072
   usr1cv8 hard nproc 131072
   

3. Шрифты и графические библиотеки: Для предотвращения падений процессов rphost при формировании печатных форм установим системные пакеты шрифтов (fontconfig, ttf-mscorefonts-installer) и библиотеку libicu.

Таким образом, комплексный подход — очистка кэша и зависшего pid-файла, проверка прав пользователя usr1cv8, настройка сети, генерация локалей и увеличение лимитов ОС — позволяет устранить ошибку «Не запущен ни один рабочий процесс» и гарантировать стабильную работу сервера 1С:Предприятия.