Как перезапустить службу 1С на сервере Linux

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

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

Ниже разобраны способы определить точное имя службы, перезапустить её штатно и принудительно, проверить результат и разобрать типичные ошибки, которые мешают серверу 1С стартовать.

Как узнать точное имя службы сервера 1С

Имя юнита systemd зависит от версии платформы и способа установки. При стандартной установке из пакетов 1С служба называется по шаблону srv1cv8-<версия>, например srv1cv8-8.3.22-1750 или srv1cv8-8.3.24-1467. Если на сервере установлено несколько версий платформы, служб может быть несколько.

Чтобы увидеть все зарегистрированные службы 1С, выполните:

systemctl list-units --type=service --all | grep srv1cv8

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

Также полезно заглянуть в каталог /etc/systemd/system/ и /usr/lib/systemd/system/ — там лежат unit-файлы, по имени которых видно, как именно зарегистрирована служба.

Штатный перезапуск через systemctl

Стандартный способ перезапуска — команда systemctl restart с правами суперпользователя. Systemd корректно остановит агент сервера и все дочерние процессы, затем запустит их заново.

1. 1
   Предупредите пользователей или дождитесь регламентного окна
2. 2
   Выполните: sudo systemctl restart srv1cv8-<версия>
3. 3
   Проверьте статус: sudo systemctl status srv1cv8-<версия>
4. 4
   Убедитесь, что процессы ragent, rmngr и rphost запущены
5. 5
   Проверьте подключение клиента к информационной базе

Команда выглядит так:

sudo systemctl restart srv1cv8-8.3.22-1750

Если нужно только остановить или только запустить службу, используются команды sudo systemctl stop srv1cv8-<версия> и sudo systemctl start srv1cv8-<версия> соответственно. Мягкая остановка через stop даёт процессам время завершить соединения, тогда как restart фактически выполняет stop и start последовательно.

Проверка статуса и диагностика после перезапуска

Сразу после перезапуска проверьте состояние службы: sudo systemctl status srv1cv8-<версия>. Статус active (running) означает, что агент сервера запущен. Статус failed или activating, который не меняется длительное время, указывает на проблему.

Дополнительно убедитесь, что в системе присутствуют три ключевых процесса кластера:

• ragent — агент сервера, принимает подключения;
• rmngr — менеджер кластера, управляет распределением нагрузки;
• rphost — рабочие процессы, обслуживающие сеансы пользователей.

ps aux | grep -E "ragent|rmngr|rphost"

Детали ошибок смотрите в журнале: sudo journalctl -u srv1cv8-<версия> -n 100 --no-pager. Также полезен технологический журнал 1С и логи кластера в каталоге /opt/1cv8/<архитектура>/<версия>/ или в каталоге, указанном в параметрах запуска агента.

Принудительное завершение зависших процессов

Если служба не останавливается штатно — команда stop зависает или статус остаётся deactivating — процессы кластера завершают принудительно. Сначала попробуйте увеличить время ожидания: systemd по умолчанию ждёт ограниченное время, после чего сам отправляет SIGKILL.

Для ручного завершения найдите PID процессов и остановите их:

ps aux | grep rphost
sudo kill -15 
если процесс не завершился:
sudo kill -9 

Сигнал -15 (SIGTERM) запрашивает корректное завершение, -9 (SIGKILL) убивает процесс немедленно без сохранения состояния. Использовать SIGKILL следует только когда SIGTERM не помог: принудительное завершение rphost обрывает транзакции пользователей, а завершение rmngr может оставить кластер в несогласованном состоянии до перезапуска.

Перезапуск через консоль кластера и отдельных процессов

Не всегда нужно перезапускать всю службу. Если проблема локализована — например, один рабочий процесс rphost «съел» всю память, — достаточно перезапустить его через консоль администрирования кластера (она доступна в Windows-версии сервера 1С и подключается к Linux-агенту по сети) или через утилиту rac.

Пример работы через rac на самом сервере:

/opt/1cv8/x86_64/8.3.22.1750/rac cluster list
/opt/1cv8/x86_64/8.3.22.1750/rac process list --cluster=

Через консоль кластера можно включить для рабочего процесса признак «выключенный», дождаться завершения его сеансов, а затем снова включить — это самый щадящий способ вывести проблемный процесс из эксплуатации без разрыва всех соединений. Также в свойствах кластера можно настроить автоматический перезапуск рабочих процессов по расписанию или при превышении порога памяти, что снижает потребность в ручных перезапусках службы.

Настройка автозапуска и автоматического восстановления

Чтобы служба сервера 1С стартовала после перезагрузки системы, включите автозапуск: sudo systemctl enable srv1cv8-<версия>. Проверить текущее состояние автозапуска можно командой systemctl is-enabled srv1cv8-<версия>.

Для автоматического восстановления после сбоя в unit-файл добавляют директивы Restart=on-failure и RestartSec=10 в секцию [Service]. После правки unit-файла обязательно выполните sudo systemctl daemon-reload, иначе systemd продолжит использовать старое описание службы.

Учитывайте, что автоматический перезапуск не решает причину падений: если служба регулярно падает, нужно анализировать технологический журнал, потребление памяти и настройки кластера, а не полагаться на Restart.

Частые проблемы при перезапуске и их решения

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

• Проверьте, не занят ли порт 1540/1541/1560: ss -tlnp | grep 154.
• Проверьте права на каталог данных кластера: владельцем должен быть пользователь, от имени которого запускается служба.
• Изучите вывод journalctl -u srv1cv8-<версия> — там обычно указана конкретная причина отказа.
• Если служба стартует, но клиенты не подключаются, проверьте firewall: порты агента и рабочих процессов должны быть открыты.

Частые вопросы