Перезапуск серверной базы 1С: от закрытия сеансов до службы
Содержание
Перезапустить базу 1С на сервере можно тремя способами: завершить сеансы и снова пустить пользователей, перезапустить рабочие процессы кластера или перезапустить службу «Агент сервера 1С:Предприятия». Чаще всего хватает первого или второго. Отдельной кнопки «перезапустить базу» в 1С нет.
Привычная ошибка — сразу останавливать службу. Так вы обрываете сеансы всех баз кластера, а не одной зависшей. Ниже способы идут от мягкого к жёсткому: переходите к следующему, только если предыдущий не помог. Всё относится к клиент-серверному варианту. У файловой базы сервера нет: достаточно закрыть программу у всех пользователей.
Подготовка: что проверить до остановки
Любой перезапуск рвёт работу людей. Несохранённые документы пропадут, а фоновые задания (обмены, закрытие месяца , обновление) оборвутся на середине.
- Узнайте, кто в базе. В консоли администрирования откройте нужную базу и раздел «Сеансы», либо выполните
rac session list(оrac— ниже). - Найдите длинные операции: проведение пачки документов, регламентные задания, выгрузки. Если идёт закрытие месяца, подождите.
- Предупредите пользователей и назначьте время. Для небольшой фирмы подойдёт обеденный перерыв или конец дня.
- Убедитесь, что есть свежая резервная копия базы и базы SQL-сервера.
Остановка службы агента сервера завершает сеансы всех информационных баз кластера, не только проблемной. Если на сервере несколько баз разных организаций, предупредите всех.
Если сервер перезагружается из-за обновления Windows или Linux, служба поднимется сама при старте системы, но только при автоматическом типе запуска. Проверьте его заранее.
Способ 1. Закрыть сеансы и запретить вход на время работ
Самый безопасный вариант, когда зависла одна база или нужен монопольный доступ для обновления структуры.
Через консоль администрирования
- Запустите «Консоль администрирования серверов 1С:Предприятия» и подключитесь к серверу.
- Раскройте нужный кластер, затем «Информационные базы» и откройте свойства базы.
- Включите блокировку начала сеансов и впишите сообщение. Например: «Идёт обслуживание, вход возобновится в 13:30».
- Перейдите в «Сеансы» этой базы, выделите все и отключите. Если сеанс не завершается, значит, он зависшей операции: перейдите ко второму способу.
- Выполните работы, затем снимите блокировку.
Запретить вход можно и ключом запуска /UC с кодом доступа: он не закрывает уже открытые сеансы, а только не пускает новых.
Что делать с регламентными заданиями
Когда база заблокирована для входа, фоновые задания тоже не стартуют. Если нужно ещё и остановить их, включите запрет регламентных заданий в свойствах базы. После работ не забудьте снять оба запрета: частая история — вход открыли, а задания остались выключенными, и через неделю не уходят обмены.
Способ 2. Перезапуск рабочих процессов кластера
Когда сеансы не завершаются, а база тормозит, помогает перезапуск рабочих процессов (rphost). Служба агента при этом остаётся включённой, остальные базы кластера задеваются только в том случае, если их сеансы обслуживает тот же процесс.
Как это устроено. Агент (ragent) запускает менеджер кластера (rmngr), а тот — рабочие процессы rphost, в которых и живут сеансы. Если убить rphost, менеджер запустит новый.
В консоли администрирования зайдите в «Рабочие процессы» и выберите зависший. Принудительно прервите его: сеансы на нём оборвутся, пользователи увидят сообщение о потере соединения и смогут зайти заново.
Через диспетчер задач или командную строку ту же операцию делают, завершив процесс rphost.exe (в Linux — rphost). Предпочтительнее консоль: так вы видите, какой именно процесс держит нужную базу.
Плановый перезапуск процессов средствами кластера
В свойствах кластера есть параметры перезапуска рабочих процессов: интервал перезапуска (в секундах) и допустимый объём памяти процесса. Если их настроить, процессы будут обновляться сами, без вашего участия. Это лучшее лекарство от «утечки» памяти, которая накапливается за недели. Типовой ориентир для интервала — сутки (86400 секунд) или реже, но подберите по нагрузке: слишком частый перезапуск мешает тяжёлым операциям.
Полный перезапуск: служба сервера в Windows и Linux
Этот уровень нужен, когда мягкие способы не помогли или менялись настройки, которые читаются только при старте.
Способ 3. Перезапуск службы в Windows
Нужен, когда не отвечает сам агент сервера или меняются настройки, которые подхватываются только при старте: каталог кластера, параметры запуска службы, обновление платформы .
Через оснастку «Службы»
- Нажмите
Win + R, введитеservices.msc. - Найдите «Агент сервера 1С:Предприятия 8.3» (в названии указана разрядность, например x86-64).
- Остановите службу и дождитесь статуса «Остановлена». Если зависла в состоянии «Остановка», переходите к принудительному завершению процессов (ниже).
- Запустите службу снова.
Через командную строку
Запускайте от имени администратора. Точное имя службы посмотрите в свойствах оснастки, оно зависит от версии платформы:
sc query state= all | findstr /i "1C"
net stop "Имя службы"
net start "Имя службы"
Если служба не останавливается
Пока агент жив, у него остаются дочерние процессы. Если остановка зависла, завершите вручную ragent.exe, rmngr.exe и rphost.exe в диспетчере задач и запустите службу заново. Это крайняя мера: возможно, придётся потом проверить, не остался ли файл блокировки в каталоге кластера, но удалять его вручную без необходимости не нужно.
Служба запускается от отдельного пользователя (обычно USR1CV8). Если после перезапуска она не стартует, проверьте, что у этого пользователя есть права на каталог кластера и на каталог журналов.
Способ 4. Перезапуск службы в Linux через systemd
В Linux сервер 1С тоже работает как служба. Её имя зависит от способа установки: для платформы 8.3 ищите юнит, в названии которого есть srv1cv8. Найдите точное имя:
systemctl list-units --type=service | grep -i 1c
Затем остановка, запуск и статус (подставьте найденное имя):
sudo systemctl stop srv1cv83
sudo systemctl start srv1cv83
sudo systemctl status srv1cv83
Одной командой — sudo systemctl restart srv1cv83. Если не хватает терпения, а stop висит, проверьте, что осталось от процессов:
ps aux | grep -E "ragent|rmngr|rphost"
Лишние процессы можно завершить через kill, а при необходимости — kill -9. Не начинайте с -9: он не даёт процессу корректно закрыть данные.
В журнале службы причины сбоя читаются так: journalctl -u srv1cv83 -n 100.
Какой способ выбрать
Сравните симптом и масштаб последствий. Чем выше строка в таблице, тем меньше вреда.
| Ситуация | Способ | Что пострадает |
|---|---|---|
| Нужен монопольный доступ или обслуживание одной базы | Закрыть сеансы, запретить вход | Только пользователи этой базы |
| Одна база тормозит, сеанс «завис» | Перезапуск рабочего процесса | Сеансы на этом процессе |
| Растёт память, процессы разбухли | Плановый перезапуск процессов средствами кластера | Почти ничего, если время выбрано удачно |
| Не отвечает агент, поменяли настройки кластера, обновили платформу | Перезапуск службы | Все базы кластера |
| Завис сервер целиком | Перезагрузка машины | Всё, что на ней запущено |
Перезагрузка самого сервера — последний довод. Перед ней остановите службу 1С штатно, а на сервере с СУБД на той же машине — ещё и службу SQL-сервера или PostgreSQL, чтобы базы закрылись без аварийных восстановлений.
Типичные ошибки при перезапуске
- ❌ Остановили службу днём, не предупредив. Бухгалтеры теряют несохранённые проводки, на звонки в поддержку уходит час. Всегда назначайте окно и пишите сообщение в блокировке входа.
- ❌ Убили
rphostво время фонового задания. Задание прервётся, и обмен или закрытие месяца придётся запускать заново. Сначала посмотрите список заданий. - ❌ Перезапустили сервер, а СУБД оставили работать с открытыми сеансами. После холодного старта SQL-сервер может долго восстанавливать базу.
- ❌ Ушли, не проверив вход. Служба «Выполняется», а клиенты не подключаются из-за закрытого порта. Всегда заходите в базу сами.
- ❌ Перезапускаете по пять раз на дню. Это симптом: ищите тяжёлый запрос, утечку памяти во внешней обработке или нехватку оперативной памяти.
Администрирование через утилиту rac
rac — консольный клиент к серверу администрирования (ras). Он удобен там, где нет графической консоли: на Linux-серверах и в скриптах. Чтобы rac работал, на сервере должен быть запущен ras; по умолчанию утилита подключается к локальному серверу на порту 1545.
Основные команды, в которых можно быть уверенным:
| Что нужно | Команда |
|---|---|
| Узнать идентификатор кластера | rac cluster list |
| Список баз кластера | rac infobase --cluster=<ид_кластера> summary list |
| Список сеансов | rac session --cluster=<ид_кластера> list |
| Завершить сеанс | rac session --cluster=<ид_кластера> terminate --session=<ид_сеанса> |
| Список рабочих процессов | rac process --cluster=<ид_кластера> list |
Если кластер защищён паролем, добавьте параметры --cluster-user и --cluster-pwd. Полный перечень параметров и подкоманд смотрите в справке: rac help и rac help session.
Пример: завершить все сеансы одной базы
Сначала найдите идентификатор базы, затем отфильтруйте сеансы по нему и завершите каждый. Делайте это скриптом, но первый запуск проведите вручную на одном сеансе: так вы убедитесь, что нужная база выбрана верно.
Идентификаторы в rac — это длинные GUID, а не имена. Копируйте их целиком из вывода предыдущей команды.
Диагностика: что проверить после запуска
Служба поднялась — это ещё не значит, что всё работает. Пройдите по порядку:
- Статус службы. «Выполняется» в Windows или
active (running)в Linux. - Процессы. Должны быть
ragent,rmngrи хотя бы одинrphost. Безrmngrкластер не работает . - Консоль администрирования. Кластер виден, базы в списке, сеансы создаются.
- Вход клиента. Откройте базу под пользователем и проведите тестовое действие.
- Журнал регистрации. Ошибки подключения к SQL-серверу и лицензий видны именно там.
journalctl.rmngr и порт сервера в параметрах подключения.Автоматизация и плановый перезапуск
Регулярный ручной перезапуск — признак того, что причину не нашли. Но плановое обслуживание по ночам бывает оправданным.
Windows: планировщик заданий
Создайте задание с правами администратора и запуском вне зависимости от входа пользователя. Действие — запуск .bat-файла:
net stop "Имя службы"
timeout /t 20
net start "Имя службы"
Пауза нужна, чтобы процессы успели завершиться. Расписание — время, когда в базе точно никого нет (например, 03:00 воскресенья).
Linux: cron или таймер systemd
Для cron добавьте строку в crontab пользователя root:
0 3 * * 0 /bin/systemctl restart srv1cv83
Это перезапуск в 03:00 по воскресеньям. Имя юнита подставьте своё. Если нужен контроль и логи, используйте таймер systemd вместо cron.
Чего не делать
- Не перезапускайте службу «на всякий случай» каждую ночь. Если базы работают стабильно, это лишний риск.
- Не ставьте перезапуск на момент регламентных заданий и обменов.
- Не оставляйте блокировку входа после ночных работ: утром люди придут в закрытую базу.