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

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

Корректный перезапуск отличается от простого «убить процесс и запустить заново»: при грубом завершении активные сеансы пользователей обрываются без сохранения данных, а незавершённые транзакции могут оставить блокировки в СУБД. Безопасная процедура включает предупреждение пользователей, контролируемую остановку службы и проверку состояния кластера после запуска.

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

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

Чтобы найти точное имя, выполните поиск по списку юнитов systemd:

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

Альтернативный способ — найти процесс агента и посмотреть, какой службе он принадлежит: ps aux | grep ragent покажет запущенный процесс, а systemctl status <PID> — имя юнита, который его запустил. Это надёжный метод, когда на сервере установлено несколько версий платформы одновременно.

Обратите внимание: если на одном сервере работают два кластера (например, тестовый и боевой на разных портах), у каждого будет своя служба. Перезапуск не той службы оборвёт сеансы не тех пользователей — проверяйте порт агента в параметрах запуска.

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

Основная команда перезапуска выглядит так (подставьте своё имя службы):

sudo systemctl restart srv1cv8-8.3.22-1750

Команда restart выполняет остановку службы и немедленный запуск. systemd при этом отправляет процессу сигнал корректного завершения и ждёт в пределах таймаута, указанного в юнит-файле. Если процесс не завершается вовремя, systemd принудительно его завершает.

1. 1
   Предупредите пользователей о плановом перезапуске или дождитесь окна без активных сеансов
2. 2
   Проверьте активные сеансы через консоль кластера или rac session list
3. 3
   Выполните sudo systemctl restart <имя службы>
4. 4
   Проверьте статус: systemctl status <имя службы> — должно быть active (running)
5. 5
   Убедитесь, что рабочие процессы запустились и кластер отвечает: rac process list
6. 6
   Проверьте, что пользователи могут подключиться к информационным базам

Раздельный вариант — sudo systemctl stop и затем sudo systemctl start — удобен, когда между остановкой и запуском нужно выполнить дополнительные действия: изменить конфигурацию, очистить каталог служебных данных или проверить освобождение портов.

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

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

Для детальной диагностики используйте журнал: journalctl -u srv1cv8-<версия> -n 100 выведет последние записи, а флаг -f позволит наблюдать журнал в реальном времени во время запуска. Типичные ошибки на этом этапе — занятый порт, недоступность каталога кластера или проблемы с правами пользователя, от имени которого работает служба.

Проверьте также, что процессы кластера действительно поднялись: ps aux | grep -E 'ragent|rmngr|rphost'. Сразу после старта рабочих процессов может быть меньше обычного — они создаются по мере поступления соединений, это нормально.

Управление кластером через утилиту rac

Помимо перезапуска всей службы, администрировать кластер можно через консольную утилиту rac, которая входит в состав платформы и находится в каталоге /opt/1cv8/x86_64/<версия>/. Она позволяет завершать отдельные сеансы и соединения без полного перезапуска — это щадящий вариант, когда проблема вызвана одним зависшим пользователем.

Типовой порядок работы: получить список кластеров (rac cluster list), затем список сеансов (rac session list --cluster=<ID>) и завершить конкретный сеанс командой rac session terminate. Для этого потребуется аутентификация администратора кластера, если она настроена.

Автоматический перезапуск и настройки systemd

Для повышения отказоустойчивости службу можно настроить на автоматический перезапуск при аварийном завершении. В юнит-файле (обычно в /etc/systemd/system/ или каталоге .d с переопределениями) добавляются параметры Restart=on-failure и RestartSec=10 — тогда systemd поднимет агент через десять секунд после сбоя.

Изменения вносятся через sudo systemctl edit srv1cv8-<версия>, после чего требуется sudo systemctl daemon-reload. Не редактируйте основной юнит-файл напрямую — при обновлении платформы он может быть перезаписан, а переопределения в каталоге .d сохранятся.

Плановый перезапуск по расписанию (например, ночной для освобождения памяти) делается через cron или systemd-таймер с той же командой restart. Такой подход допустим, но лучше сначала разобраться в причинах роста потребления памяти — регулярный перезапуск маскирует проблему, а не решает её.

Типичные ошибки и риски при перезапуске

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

Вторая группа ошибок связана с тем, что после перезапуска служба не поднимается: занят порт (предыдущий процесс не завершился), повреждены права на каталог кластера, закончилось место на диске. Всегда проверяйте статус и журнал, а не ограничивайтесь отправкой команды restart.

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