При развертывании сервера 1С:Предприятие на операционных системах семейства Linux (Debian, Ubuntu, Astra Linux) системные администраторы, занимающиеся вопросами создания защищенной IT инфраструктуры на базе Astra Linux, часто сталкиваются с ситуацией, когда после установки .deb пакетов (что также актуально при развертывании тестового кластера на Ubuntu) служба srv1cv83 отказывается запускаться автоматически или переходит в состояние active (exited) сразу после старта. При этом ручной запуск процесса ragent под пользователем root проходит успешно, что вводит в заблуждение относительно причин неисправности.
В этой статье мы подробно разберем, включая вопросы автоматизации процессов установки и обновления СУБД PostgreSQL и 1С в Astra Linux, почему стандартные скрипты инициализации могут давать сбой, как современные механизмы управления сессиями (PAM) влияют на работу фоновых процессов и какие шаги необходимо предпринять для создания надежного сервиса.
Проанализируем типичное поведение системы. Когда мы запускаем службу через systemctl start srv1cv83, система выполняет скрипт, находящийся в /etc/init.d/. В старых версиях платформы (до 8.3.21) этот скрипт использует команду su для переключения контекста на пользователя usr1cv8. Проблема заключается в том, что современные дистрибутивы Linux используют пакет libpam-systemd, который строго контролирует жизненный цикл пользовательских процессов.
Разберем ситуацию: как только скрипт инициализации завершает свою работу, сессия пользователя usr1cv8, созданная через su, считается закрытой. Система systemd-logind видит окончание сессии и, следуя настройкам безопасности по умолчанию, «убивает» все дочерние процессы, запущенные в рамках этой сессии, включая наш ragent, rmngr и rphost (для управления которыми часто используется консоль администрирования серверов (ras) для Linux). Именно поэтому в логах мы видим успешный старт, а через несколько секунд — сообщение об ошибке или пустой список процессов.
Рассмотрим наиболее правильный и «чистый» способ решения проблемы, который рекомендуют специалисты технической поддержки Astra Linux. Нам необходимо запретить системе принудительно завершать процессы служебного пользователя 1С после закрытия его сессии.
Для этого выполним следующие шаги:
/etc/systemd/logind.conf с правами суперпользователя.KillUserProcesses. По умолчанию он может быть закомментирован или установлен в yes.KillUserProcesses=no. Это глобальная настройка, которая предотвратит очистку процессов для всех пользователей.KillExcludeUsers, добавив туда нашего пользователя: KillExcludeUsers=root usr1cv8.После внесения изменений необходимо перезагрузить службу логина или всю систему целиком:
systemctl restart systemd-logind
Использование старых скриптов /etc/init.d/srv1cv83 (LSB) в современной системе — это путь к накоплению технических ошибок. Слой совместимости systemd-sysv-generator часто ошибается в определении статуса службы. Посмотрим, как создать современный Unit-файл, который обеспечит корректный мониторинг процессов.
Создадим файл /etc/systemd/system/1c-server.service и наполним его следующим содержимым:
[Unit]
Description=1C:Enterprise Server 8.3
After=network.target network-online.target postgresql.service
[Service]
Type=forking
User=usr1cv8
Group=grp1cv8
ExecStart=/opt/1cv8/x86_64/8.3.XX.XXXX/ragent -daemon
PIDFile=/home/usr1cv8/.1cv8/1C/1cv8/ragent.pid
Restart=always
KillMode=process
[Install]
WantedBy=multi-user.target
Обратите внимание на параметр Type=forking. Он указывает systemd, что основной процесс породит дочерний и завершится — это именно то, что делает ragent с флагом -daemon. Также важно указать правильный путь к исполняемому файлу (замените 8.3.XX.XXXX на вашу версию платформы).
Если по каким-то причинам мы обязаны использовать стандартный скрипт /etc/init.d/srv1cv83, разберем способ его адаптации. Основная проблема в нем — строка запуска через su -s /bin/bash. Проанализируем более надежный вариант запуска с использованием start-stop-daemon, который корректно отсоединяет процесс от терминала и сохраняет его PID.
Заменим строку запуска в скрипте на следующую конструкцию:
start-stop-daemon --start --chuid "$SRV1CV8_USER" --oknodo \
--pidfile "$SRV1CV8_PIDFILE" \
--exec /usr/bin/env KRB5_KTNAME="$SRV1CV8_KEYTAB" \
"$SRV1CV8_BINDIR/ragent" -- "-daemon"
Этот метод позволяет избежать проблем с переменными окружения и гарантирует, что systemd сможет отслеживать состояние службы через PID-файл.
Часто проблема «Service failed to start» кроется не в самом скрипте, а в данных, с которыми он работает. Если мы хотя бы один раз запустили сервер от имени root, в домашней директории пользователя usr1cv8 появятся файлы, принадлежащие суперпользователю. В следующий раз служба, запущенная от usr1cv8, не сможет их прочитать или перезаписать.
Выполним обязательную проверку и исправление прав доступа:
chown -R usr1cv8:grp1cv8 /home/usr1cv8/.1cv8/
chown -R usr1cv8:grp1cv8 /opt/1cv8/
Также стоит обратить внимание на целостность файла списка баз и кластеров 1cv8wsrv.lst. Если этот файл поврежден (например, содержит только нули после аварийного отключения питания), сервис не запустится. Посмотрим на структуру здорового файла: он должен содержать уникальный идентификатор кластера и сетевое имя сервера. В случае подозрений на повреждение, попробуйте временно переименовать папку srvinfo и запустить службу «с нуля» — если сервер стартует, значит, проблема была в конфигурационных файлах кластера.
Разберем еще один важный аспект: лимиты операционной системы. По умолчанию в Linux для пользователя установлены довольно жесткие ограничения на количество открытых файлов (nofile). Сервер 1С активно работает с сокетами и временными файлами, поэтому лимиты нужно расширить.
Отредактируем файл /etc/security/limits.conf, добавив в конец следующие строки:
usr1cv8 soft nofile 65535
usr1cv8 hard nofile 65535
usr1cv8 soft nproc 65535
usr1cv8 hard nproc 65535
Без этих правок сервер может успешно стартовать, но «падать» или выдавать ошибки при подключении большого количества пользователей.
В заключение отметим, что начиная с версии 8.3.21, компания 1С официально поставляет нативные .service файлы для systemd вместе с новым инсталлятором в формате .run. Если у вас есть возможность обновить платформу, это будет самым эффективным способом избавиться от проблем с автозапуском раз и навсегда.