Рестарт кластера 1С на Linux без потери сеансов и данных

Серверная 1С на Linux перезапускается одной командой: sudo systemctl restart srv1cv83. Если ваш сервис называется иначе, найдите его через systemctl list-units | grep -i 1c. Но команда убьёт все сеансы и прервёт регламентные задания, поэтому сначала смотрят, кто в базе, и только потом жмут Enter.

Типичная картина: в 17:40 бухгалтерия закрывает квартал, в 17:45 «зависает» фоновое задание, и администратору звонят три человека сразу. Рестарт помогает в таких случаях часто, но делать его вслепую нельзя.

Что проверить до перезапуска сервера 1С

Рестарт агента сервера обрывает все клиентские соединения. Несохранённые документы пропадут, а длинные операции (закрытие месяца , обмен, переиндексация) откатятся.

Перед остановкой пройдите по списку:

• 👥 Кто сейчас работает: список сеансов (способ ниже).
• ⏳ Какие фоновые и регламентные задания выполняются.
• 💾 Есть ли свежая резервная копия баз и когда она сделана.
• 🔌 Нет ли активных обменов с другими базами и сайтом.
• 📣 Предупреждены ли пользователи: сообщение в чат и блокировка новых входов.

Как посмотреть активные сеансы

Утилита администрирования rac ставится вместе с серверной частью платформы. Сначала узнайте идентификатор кластера:

rac cluster list

Затем выведите сеансы, подставив найденный cluster:

rac session list --cluster=<идентификатор_кластера>

В выводе смотрите поля user-name, app-id и started-at. Строки с app-id : 1CV8C и 1CV8 — живые пользователи. Строки BackgroundJob — фоновые задания, их тоже лучше дождаться.

Если rac отвечает ошибкой подключения, значит не запущен сервер администрирования ras. Запустите его отдельно, например ras cluster --daemon (порт по умолчанию 1545).

Мягкое отключение пользователей

Предупредите людей и закройте вход в базу на время работ. Это делается в консоли кластера или командой:

rac infobase update --cluster=<id> --infobase=<id_базы> \
  --sessions-deny=on --denied-message="Технические работы, вход временно закрыт" \
  --denied-from="2026-10-07 18:00:00" --denied-to="2026-10-07 18:30:00"

Идентификатор базы берётся из rac infobase summary list --cluster=<id>. После работ не забудьте снять блокировку: --sessions-deny=off.

Способы перезапуска сервера 1С в Linux

Вариантов три, и они различаются по тому, насколько бережно обходятся с сеансами.

Через systemd

Современные дистрибутивы (Ubuntu, Debian, Astra Linux, РЕД ОС, Alt) управляют службой через systemctl:

sudo systemctl restart srv1cv83

Сервис при этом перечитывает свои параметры запуска. Если вы меняли файл с настройками сервиса или сам unit, перед рестартом выполните sudo systemctl daemon-reload.

Через init-скрипт

В старых системах без systemd остался скрипт в /etc/init.d:

sudo /etc/init.d/srv1cv83 restart

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

Проверка статуса службы до и после рестарта

Состояние службы показывает:

systemctl status srv1cv83

Нужная строка начинается с Active: active (running). Если там failed или activating (auto-restart), служба падает при старте, и смотреть надо журнал (раздел про логи ниже).

Быстрая проверка, что процессы поднялись:

ps -ef | grep -E "ragent|rmngr|rphost" | grep -v grep

Должны быть как минимум ragent (агент сервера) и rmngr (менеджер кластера). Процессы rphost появятся после первого подключения пользователей: рабочие процессы создаются по требованию.

Полный рестарт: остановка и запуск по отдельности

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

1. Остановите службу: sudo systemctl stop srv1cv83.
2. Убедитесь, что процессов не осталось: pgrep -a -E "ragent|rmngr|rphost". Вывод должен быть пустым.
3. Если процессы зависли и не уходят, подождите минуту, затем завершите их: sudo pkill -TERM rphost, а при неудаче sudo pkill -KILL ragent rmngr rphost.
4. Проведите нужные работы.
5. Запустите службу: sudo systemctl start srv1cv83.

Жёсткое kill -9 оставьте на крайний случай. После него в каталоге данных кластера могут остаться файлы блокировок, и старт пойдёт с замечаниями в журнале.

Если нужен только «сброс» зависшего сеанса

Часто достаточно убить один сеанс, а не весь сервер. Найдите его в rac session list, возьмите значение поля session и выполните:

rac session terminate --cluster=<id> --session=<id_сеанса>

Так пользователь теряет только свою сессию, остальные работают.

Перезапуск кластера серверов 1С из нескольких узлов

Если рабочих серверов несколько, рестарт идёт по одному узлу, а не по всем сразу. Иначе кластер полностью исчезнет, и пользователи увидят «Сервер недоступен».

Порядок такой:

1. Начните с вторичных (рабочих) серверов, где нет главного менеджера кластера.
2. Дождитесь, пока узел вернётся в список: rac server list --cluster=<id>.
3. Только после этого переходите к следующему.
4. Центральный сервер, на котором стоит основной менеджер, перезапускайте последним.

Перед рестартом можно перевести узел в режим, где он не принимает новые подключения, и дождаться, пока сеансы разойдутся. Тогда пользователей просто не заметят.

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

rac cluster list
rac infobase summary list --cluster=<id>
rac server list --cluster=<id>

Если кластер после старта показывает пустой список баз, не паникуйте: база подтягивается, пока менеджер кластера читает свой реестр. Подождите 20-30 секунд и повторите.

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

Порты и сеть

Служба в статусе active ещё не значит, что клиенты подключатся. Проверьте, что сервер слушает нужные порты:

sudo ss -tlnp | grep -E "1540|1541|1545|156[0-9]|15[7-9][0-9]"

Стандартная раскладка выглядит так:

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

Для проверки с рабочего места хватит nc -zv имя_сервера 1540 или telnet имя_сервера 1540.

Логи и мониторинг

Первые 5-10 минут после рестарта смотрите журнал: именно там видно, что не так. Фильтруйте по слову error или fail, если вывод длинный: journalctl -u srv1cv83 --since "-15min" | grep -iE "error|fail".

sudo journalctl -u srv1cv83 -n 100 --no-pager

Для наблюдения в реальном времени добавьте -f. Технологический журнал и журналы кластера лежат в домашнем каталоге пользователя службы, обычно в ~/.1cv8/ под usr1cv8, а точное место задаёт файл logcfg.xml, если вы его настраивали.

Вместе с логами следите за нагрузкой. Сразу после старта все пользователи входят одновременно, и серверу плохо:

• 📈 top или htop: смотрите, сколько памяти и процессора съедают rphost.
• 🧠 free -h: свободная память и своп. Если своп растёт, рабочих процессов слишком много на данный объём ОЗУ.
• 💽 df -h: место на разделах с данными кластера и журналами.

Рост памяти у rphost в течение дня штатный: платформа держит в памяти кэши данных и сеансов, и до первых часов работы это нормально. Для сравнения запишите значения сразу после старта и через два-три часа.

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

Перезапуск после обновления платформы

После установки новой версии платформы «просто рестарт» не сработает. Служба продолжает ссылаться на старый каталог, поэтому нужно перенацелить её на новый.

Порядок действий:

1. Остановите службу и убедитесь, что процессы ушли.
2. Установите новую версию серверных пакетов.
3. Проверьте, куда указывает unit или init-скрипт: путь содержит номер версии, например /opt/1cv8/x86_64/8.3.х.хххх/.
4. Обновите путь на новую версию и выполните sudo systemctl daemon-reload.
5. Запустите службу и проверьте systemctl status.

Клиентские компьютеры должны обновиться до той же версии, иначе пользователи увидят предложение обновить клиент или отказ в подключении. Какой релиз платформы актуален сейчас, смотрите на сайте релизов 1С: номера здесь не приводятся намеренно, они быстро устаревают.

Автоматизация: рестарт по расписанию через cron и systemd

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

Минимальный скрипт /usr/local/bin/restart-1c.sh:

#!/bin/bash
LOG=/var/log/restart-1c.log
echo "$(date '+%F %T') старт рестарта" >> "$LOG"

systemctl restart srv1cv83
sleep 30

if systemctl is-active --quiet srv1cv83; then
    echo "$(date '+%F %T') служба active" >> "$LOG"
else
    echo "$(date '+%F %T') ОШИБКА: служба не поднялась" >> "$LOG"
    exit 1
fi

Не забудьте chmod +x /usr/local/bin/restart-1c.sh. Запись в crontab для root (sudo crontab -e), рестарт в 03:30 по воскресеньям:

30 3 * * 0 /usr/local/bin/restart-1c.sh

Расписание из пяти полей читается слева направо: минута, час, день месяца, месяц, день недели.

Что добавить для надёжности:

• 📨 Отправку уведомления (письмо или Telegram-бот) при ошибке, чтобы утром не узнавать о падении от пользователей.
• 🔒 Проверку, что нет активных сеансов, перед рестартом: скрипт читает rac session list и отменяет рестарт, если есть живые пользователи.
• 🔁 Для самой службы в unit можно задать Restart=on-failure, тогда systemd поднимет её после аварийного падения без вашего участия.

Если у вас системный таймер вместо cron, логика та же: unit типа .timer вызывает .service со скриптом. Для одного сервера cron проще и понятнее.

Что делать, если сервер 1С не запускается после рестарта

Разберём частые причины по симптомам.

Если ничего не помогло: запустите агент сервера вручную от имени служебного пользователя прямо в терминале, без systemd. Ошибка тогда выводится на экран, и причина видна сразу. Для этого используйте тот же путь и параметры, что указаны в unit-файле службы.

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