1С: Ошибка службы systemd при автозапуске srv1cv83 (Failed with result exit-code)
Механизм управления службой 1С через systemd
В современных дистрибутивах Linux запуск и мониторинг состояния кластера серверов 1С:Предприятие осуществляется через системный менеджер systemd (служба srv1cv83.service / srv1cv8-8.3.X.X.service). При старте операционной системы или ручном вызове systemctl start srv1cv83 служба мгновенно переходит в статус Failed / activating (auto-restart), выводя ошибку:
«Job for srv1cv83.service failed because the control process exited with error code. See "systemctl status srv1cv83.service" and "journalctl -xeu srv1cv83.service" for details.»
Бизнес-риски
Сервер 1С не поднимается после плановой ночной перезагрузки или обновления ОС, простой предприятия в начале рабочего дня, срыв регламентных фоновых обменов.
Коды возврата (Exit Codes) службы 1С в systemd
| Код возврата | Статус systemd | Первопричина |
|---|---|---|
exit-code 1/FAILURE | Process exited | Синтаксическая ошибка в аргументах запуска ragent или отсутствие каталога. |
exit-code 127 | Executable not found | Неверный путь к бинарному файлу ragent в директиве ExecStart. |
exit-code 217/USER | Cannot determine UID | Пользователь usr1cv8 удален или заблокирован в /etc/passwd. |
exit-code 134/ABRT | Aborted | Падение glibc (Segmentation Fault) из-за несовместимости библиотек. |
Регламент диагностики и исправления службы systemd 1С
Сценарий 1: Глубокий анализ логов journalctl
Для выявления реальной причины сбоя запросите системные логи unit-файла:
# Просмотр статуса и последних строк вывода службы:
sudo systemctl status srv1cv83.service -l
# Детальный вывод системного журнала с момента последней попытки старта:
sudo journalctl -u srv1cv83.service -e --no-pagerСценарий 2: Создание эталонного systemd unit-файла для 1С 8.3
Штатные скрипты инициализации SysVinit (/etc/init.d/srv1cv83) устарели. Создайте современный нативный systemd unit:
# Создание эталонного сервиса /etc/systemd/system/srv1cv83.service
sudo bash -c 'cat << EOF > /etc/systemd/system/srv1cv83.service
[Unit]
Description=1C:Enterprise 8.3 Server Cluster
After=network.target postgresql.service
Wants=postgresql.service
[Service]
Type=simple
User=usr1cv8
Group=grp1cv8
Environment="LANG=ru_RU.UTF-8"
Environment="LC_ALL=ru_RU.UTF-8"
ExecStart=/opt/1cv8/x86_64/8.3.24.1667/ragent -port 1540 -regport 1541 -range 1560:1591 -seclev 0 -pingPeriod 1000 -pingTimeout 5000 -d /home/usr1cv8/.1cv8/1C/1cv8/reg_1541
Restart=always
RestartSec=5
LimitNOFILE=131072
LimitNPROC=65536
KillMode=process
[Install]
WantedBy=multi-user.target
EOF'
# Применение и включение автозагрузки:
sudo systemctl daemon-reload
sudo systemctl enable srv1cv83
sudo systemctl start srv1cv83Сценарий 3: Проверка блокировок портов кластера (1540, 1541, 1560-1591)
Если служба не может забиндить порты, проверьте, не заняты ли они «зависшими» процессами:
# Поиск процессов, слушающих порты 1С кластера:
sudo ss -tulpn | grep -E '1540|1541|1560'
# Если порты заняты старыми процессами -> убейте их:
sudo fuser -k 1540/tcp 1541/tcpТиповые ошибки администраторов
- Несоответствие путей после обновления платформы: Обновили платформу с версии 8.3.23 на 8.3.24, но в unit-файле
srv1cv83.serviceпутьExecStartостался указывать на старую несуществующую директорию. - Запуск службы до старта СУБД: Отсутствие директив
After=postgresql.serviceприводит к тому, что 1С пытается подключиться к СУБД, которая еще не успела подняться.
Инженеры ITSTM разработают отказоустойчивые сценарии запуска, настроят правильный порядок инициализации зависимостей и вотчдоги автоматического перезапуска.
Частые вопросы (FAQ)
Почему systemctl status пишет 'Active: auto-restart', но сервер не работает?
Опция Restart=always заставляет systemd циклически перезапускать падающий процесс. Процесс стартует, падает за 0.1 сек и снова перезапускается (CrashLoop).
Как запустить несколько независимых кластеров 1С на одном Linux-сервере?
Создайте два разных unit-файла (например, srv1cv83-prod и srv1cv83-test) с разными сетевыми портами (1540/1541 и 2540/2541) и разными каталогами данных (-d).
Что означает директива KillMode=process?
Она указывает systemd при остановке службы завершать только главный процесс ragent, позволяя дочерним rphost корректно сохранить сеансовые данные перед выходом.
Где хранятся логи падения ragent, если journalctl пуст?
Смотрите системный лог /var/log/syslog или /var/log/messages, а также проверьте дампы ядра в /var/lib/systemd/coredump/ (команда coredumpctl list).