Перезапуск сервера 1С:Предприятия в Linux: команды и диагностика

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

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

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

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

1. Узнайте, кто сейчас в базе. Консоль кластера (раздел «Сеансы») или утилита rac покажут активные соединения.
2. Проверьте регламентные задания: идёт ли закрытие месяца , обмен, загрузка банковских выписок.
3. Предупредите пользователей и назначьте время. Для небольшой базы хватает 10-15 минут.
4. Убедитесь, что есть свежая копия базы и каталога кластера.
5. Откройте вторую SSH-сессию. Если первая оборвётся, у вас останется рабочий доступ.

Как найти службу и посмотреть её статус

Служба 1С в Linux обычно называется srv1cv83, но название зависит от версии платформы и способа установки. Проверьте:

systemctl list-units --type=service | grep -i 1c
systemctl status srv1cv83

В выводе смотрите на строку Active:. Значение active (running) означает, что процесс жив. Это не гарантирует, что кластер отвечает: зависший ragent тоже числится запущенным.

Проверьте процессы и порты:

ps aux | grep -E 'ragent|rphost|rmngr' | grep -v grep
ss -tlnp | grep -E '1540|1541|15[6-9][0-9]'

Что должно быть в норме:

• 🔹 ragent — агент сервера, слушает порт 1540;
• 🔹 rmngr — менеджер кластера, порт 1541;
• 🔹 rphost — рабочие процессы, порты из диапазона 1560-1591.

Если ragent есть, а порт 1540 никто не слушает, служба фактически мертва.

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

Это основной способ. Он корректно останавливает процессы и поднимает их заново под нужным пользователем (обычно usr1cv8).

sudo systemctl restart srv1cv83

То же самое двумя шагами, если хотите контролировать паузу:

sudo systemctl stop srv1cv83
sleep 10
sudo systemctl start srv1cv83

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

systemctl status srv1cv83
journalctl -u srv1cv83 -n 50 --no-pager

Через минуту зайдите в консоль кластера или откройте базу клиентом. Проверка только по status ненадёжна.

Что делать, если служба не стартует

Типичные причины и быстрые проверки:

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

Иногда перезапускать всю службу избыточно. Если зависла одна база или один сеанс, достаточно управлять кластером точечно. Для этого есть консольная утилита rac и сервер администрирования ras.

Запустите ras (если он не запущен как служба):

/opt/1cv8/x86_64/8.3.xx.xxxx/ras cluster --daemon

Версию в пути замените на свою. Дальше работаем через rac:

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

Идентификатор кластера выводится первой командой. Найдите нужный сеанс и завершите его:

rac session terminate --cluster=<id_кластера> --session=<id_сеанса>

Так вы отключите «подвисшего» пользователя, не трогая остальных.

Когда достаточно завершить сеансы

• ✅ Пользователь не может выйти из базы или заблокировал объект.
• ✅ Нужно снять сеансы перед обновлением или выгрузкой базы.
• ✅ Зависло фоновое задание, а остальные работают нормально.

Когда без перезапуска службы не обойтись

• ❌ Кластер не отвечает ни в консоли, ни в rac.
• ❌ Рабочие процессы rphost выросли по памяти и не освобождают её.
• ❌ После смены настроек кластера они не применились.

Для рабочих процессов есть мягкая альтернатива: в свойствах рабочего сервера задайте перезапуск процессов по расписанию. Тогда 1С сама пересоздаёт rphost, не обрывая службу целиком. Точное расположение настройки зависит от версии консоли, ищите в свойствах рабочего сервера параметры интервала перезапуска и допустимого объёма памяти.

Зависание службы: как остановить и поднять принудительно

Бывает, что systemctl restart висит минуту, две, а потом падает по таймауту. Это значит, что процессы не реагируют на сигнал завершения.

Действуйте по порядку.

1. Дайте команде отработать до таймаута. По умолчанию systemd ждёт 90 секунд.
2. Если не помогло, найдите оставшиеся процессы:

ps -eo pid,user,etime,rss,cmd | grep -E 'ragent|rmngr|rphost' | grep -v grep

3. Попросите их завершиться штатно:

sudo pkill -TERM -u usr1cv8 -f 'ragent|rmngr|rphost'

4. Подождите 10-20 секунд и проверьте снова.
5. Только если процессы живы, применяйте жёсткое завершение:

sudo pkill -KILL -u usr1cv8 -f 'ragent|rmngr|rphost'

6. Запустите службу: sudo systemctl start srv1cv83.

Мини-кейс: служба «active», а база не открывается

Пользователи жалуются на ошибку соединения с сервером, systemctl status показывает active (running). Порт 1541 не слушается, rmngr отсутствует в списке процессов. Остался только ragent, который завис при попытке поднять менеджер кластера.

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

Вывод простой: перед тем как перезапускать в третий раз, посмотрите df -h.

Где искать причину сбоя: логи и журналы

Перезапуск лечит симптом. Если сбои повторяются, нужна причина. Смотрите три источника.

Журнал systemd. Показывает запуск и остановку службы, коды завершения:

journalctl -u srv1cv83 --since "2 hours ago" --no-pager

Ищите строки с Main process exited, code=killed, signal=KILL. Сигнал KILL без вашего участия часто означает, что процесс убил механизм нехватки памяти.

Проверка нехватки памяти:

dmesg -T | grep -i -E 'out of memory|oom'

Если там записи про rphost, серверу не хватает оперативной памяти или у рабочих процессов нет ограничений.

Журналы кластера. Лежат внутри каталога данных кластера (по умолчанию в домашнем каталоге пользователя usr1cv8, подкаталог .1cv8). Точный путь зависит от того, как вы запускали службу: параметр -d в команде запуска указывает каталог. Посмотреть его можно в systemctl cat srv1cv83.

Технологический журнал. Включается файлом logcfg.xml и пишет события платформы: исключения, долгие вызовы, блокировки. Для разбора зависаний включайте события EXCP и TLOCK, но не оставляйте подробный журнал навсегда: он быстро занимает диск.

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

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

1. Установите новую платформу. Старая остаётся в соседнем каталоге вида /opt/1cv8/x86_64/<версия>/.
2. Посмотрите, куда указывает текущий юнит: systemctl cat srv1cv83, строка ExecStart.
3. Поправьте путь на новую версию через sudo systemctl edit --full srv1cv83 или переустановите юнит штатным скриптом из каталога платформы.
4. Выполните sudo systemctl daemon-reload, затем sudo systemctl restart srv1cv83.
5. Откройте консоль кластера и убедитесь, что рабочий сервер поднялся на нужной версии.

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

Что требует перезапуска, а что нет

Безопасность запуска

Служба не должна работать от root. Проверьте владельца процессов командой ps -o user,cmd -C ragent. В колонке пользователя ожидаем usr1cv8. Если там root, исправьте параметры юнита (User= и Group=) и права на каталог кластера: sudo chown -R usr1cv8:grp1cv8 <каталог_кластера>. Имя группы проверьте по id usr1cv8, оно зависит от установки.

Автоматизация: плановый перезапуск и контроль

Если сервер требует регулярной «встряски», это повод искать причину. Но автоматический перезапуск по ночам — вполне рабочий компромисс, пока причина не найдена.

Плановый перезапуск через cron

Откройте таблицу задач суперпользователя: sudo crontab -e. Добавьте строку:

30 3 * * 0 /bin/systemctl restart srv1cv83

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

Вместо cron можно использовать таймер systemd, он удобнее для журналирования. Но для одной команды cron проще.

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

Чтобы systemd сам поднимал службу после сбоя, добавьте в юнит секцию:

[Service]
Restart=on-failure
RestartSec=15

Править лучше через sudo systemctl edit srv1cv83: изменения ляжут в отдельный файл и переживут обновление платформы . После правки выполните sudo systemctl daemon-reload.

Простой скрипт проверки

Скрипт проверяет, слушается ли порт 1541, и перезапускает службу, если нет:

#!/bin/bash
if ! ss -tln | grep -q ':1541 '; then
  logger "1C: порт 1541 не отвечает, перезапуск"
  systemctl restart srv1cv83
fi

Запускайте его из cron раз в 5 минут. Но будьте осторожны: слепой перезапуск при каждой неудачной проверке создаст цикл. Добавьте счётчик попыток или отправку уведомления администратору.

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