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

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

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

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

Как называется служба 1С и как её найти

При установке сервера 1С из пакетов вендора создаётся unit-файл systemd. Его имя зависит от версии платформы: для 8.3.22 это обычно srv1cv8-8.3.22.XXXX, для более ранних версий — srv1cv8-8.3.XX.XXXX или просто srv1cv8. Точное имя подскажет сама система.

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

systemctl list-units --type=service | grep -i 1c
systemctl list-unit-files | grep -i srv1c

Если сервер установлен вручную без пакетов (запуск скриптом или через rc.local), службы systemd может не быть — тогда агент запускается процессом ragent, и управлять им придётся через завершение процесса и повторный запуск. Такой способ считается устаревшим и усложняет сопровождение.

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

Базовый сценарий, подходящий для большинства ситуаций, выглядит так. Подставьте фактическое имя вашей службы вместо srv1cv8.

1. 1
   Узнайте имя службы: systemctl list-units | grep -i 1c
2. 2
   Проверьте активные сеансы в консоли кластера или через rac session list
3. 3
   Предупредите пользователей о перерыве в работе
4. 4
   Выполните sudo systemctl restart srv1cv8
5. 5
   Проверьте статус: systemctl status srv1cv8
6. 6
   Убедитесь, что информационные базы доступны и сеансы подключаются

Команда restart последовательно выполняет остановку и запуск. Если нужно контролировать каждый этап отдельно, используйте пару команд:

sudo systemctl stop srv1cv8
sudo systemctl start srv1cv8

Между остановкой и запуском имеет смысл выдержать паузу в несколько секунд, чтобы рабочие процессы успели завершиться и освободить порты. Проверить, что процессы действительно завершились, можно командой ps aux | grep rphost — в выводе не должно остаться процессов платформы.

sudo systemctl restart srv1cv8 && systemctl status srv1cv8 --no-pager

Подготовка: что сделать до перезапуска

Главный риск перезапуска — обрыв активных сеансов пользователей. Незавершённые транзакции откатятся, несохранённые данные в открытых формах будут потеряны, а в файлах журналов СУБД могут остаться записи о разорванных соединениях. Поэтому перезапуск в рабочее время без предупреждения — плохая практика.

Список активных сеансов можно получить через утилиту администрирования rac:

/opt/1cv8/x86_64/current/rac session list --cluster=ID_КЛАСТЕРА

Если сеансов много, дождитесь окончания рабочего дня или попросите пользователей выйти. Альтернатива — заблокировать новые подключения к информационным базам через консоль кластера, дождаться завершения оставшихся сеансов и только потом перезапускать службу.

Проверка результата после перезапуска

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

Журнал службы смотрят через journalctl — это первое место, где нужно искать причину проблем:

sudo journalctl -u srv1cv8 -n 100 --no-pager
sudo journalctl -u srv1cv8 -f

Вторая команда показывает журнал в реальном времени — удобно наблюдать за запуском. Также проверьте технологический журнал платформы и файлы реестра кластера в каталоге srvinfo, если служба стартует, но базы недоступны.

Если служба не запускается или падает

Типичная ситуация: после restart служба уходит в статус failed. Причины чаще всего сводятся к нескольким вариантам, которые проверяют последовательно.

Если процесс rphost завис и не реагирует на штатную остановку, найдите его PID и завершите принудительно:

ps aux | grep rphost
sudo kill -9 PID_ПРОЦЕССА

Использовать kill -9 следует только после того, как штатная остановка не сработала: принудительное завершение не даёт процессу корректно закрыть соединения с СУБД. После этого перед запуском убедитесь, что порты освободились: ss -tlnp | grep 154.

Особые сценарии

Несколько версий платформы на одном сервере

Когда на сервере установлено несколько версий 8.3, каждая обычно имеет собственную службу. Перед перезапуском убедитесь, что вы работаете именно с той версией, на которой крутится рабочий кластер. Актуальную версию покажет вывод ps aux | grep ragent — в пути к исполняемому файлу будет номер версии.

Перезапуск без systemd

На старых системах с SysV init используется команда service srv1cv8 restart или скрипт в /etc/init.d. Если агент запущен вручную, его останавливают завершением процесса ragent, а запускают командой из каталога платформы с параметрами -daemon. Такой запуск стоит по возможности перевести на systemd — это упростит автозагрузку и мониторинг.

Кластер из нескольких серверов

В многосерверном кластере перезапускайте агенты по одному, начиная с резервных узлов. Центральный сервер кластера перезапускайте последним и только убедившись, что остальные узлы работают. Одновременный перезапуск всех узлов приведёт к полной остановке обслуживания и перестройке реестра кластера.

Изменение параметров запуска службы

Если перезапуск нужен для применения новых параметров (например, уровня отладки или пути к srvinfo), правьте unit-файл, а не запускайте агент вручную с другими ключами. Файл обычно находится в /etc/systemd/system/ или /usr/lib/systemd/system/.

После редактирования обязательно выполните sudo systemctl daemon-reload, иначе systemd продолжит использовать старую конфигурацию. Затем перезапустите службу и проверьте, что новые параметры применились: ps aux | grep ragent покажет фактические аргументы командной строки.

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