Как закрыть зависшие сеансы в 1С 8.3.20.1674, если перезапуск служб не помогает?

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

Выясним причину проблемы

Проблема ветки 8.3.20 (в частности релиза 1674) кроется в изменении механизма хранения сеансовых данных. В этой версии платформа начала более агрессивно кэшировать данные сеансов в файловом хранилище сервера приложений для обеспечения отказоустойчивости. Если служба ragent завершается некорректно или слишком быстро, менеджер кластера rmngr не успевает очистить временные файлы в каталоге srvinfo. При последующем запуске службы 1С считывает сохраненные данные и восстанавливает сеансы, которые фактически уже не активны на стороне клиента.

Метод 1: Принудительная перезагрузка сервера через планировщик задач

Одним из самых простых, хотя и радикальных способов, является настройка автоматической перезагрузки всего физического или виртуального сервера перед началом ночного бэкапа. Рассмотрим, как это настроила автор темы. Создадим задание в планировщике задач Windows, которое будет выполнять следующую команду:

Программа: %SYSTEMROOT%\System32\shutdown.exe

Аргументы:

/r /f /t 90 /d p:0:0 /c "Плановый перезапуск сервера для очистки сеансов 1С. Отмена: shutdown.exe /a"

Параметр /r инициирует перезагрузку, /f принудительно закрывает все приложения, а /t 90 дает администратору запас в полторы минуты на случай, если перезапуск нужно будет отменить вручную.

Метод 2: Ручная очистка сеансовых данных (snaccnt)

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

1. Остановим службу 1C:Enterprise 8.3 Server Agent.
2. Убедимся, что процессы rphost.exe, rmngr.exe и ragent.exe завершены. Если они зависли, завершим их принудительно.
3. Перейдем в каталог данных сервера 1С. Обычно он находится по пути: C:\Program Files\1cv8\srvinfo\reg_1541\.
4. Внутри папок с идентификаторами информационных баз (длинные буквенно-цифровые названия) найдем папку snaccnt.
5. Удалим содержимое папок snaccnt. Именно здесь платформа хранит информацию о «живучих» сеансах.
6. Удалим временные файлы из папок temp в том же каталоге srvinfo.
7. Запустим службу 1С обратно.

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

Метод 3: Использование кода разрешения (параметр /UC)

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

При установке блокировки в консоли администрирования или программно, необходимо заполнить поле «Код разрешения» (например, слово ServiceAdmin). Чтобы зайти в базу под этой блокировкой, запустим клиент 1С с дополнительным параметром в строке запуска:

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /S "ServerName\BaseName" /UC "ServiceAdmin"

Важно помнить, что в релизах около 8.3.20.1613–1674 наблюдался баг, при котором ключ /UC мог игнорироваться. В этом случае поможет только обновление платформы до исправленных версий (например, 8.3.20.1710 или выше).

Метод 4: Автоматизация через командный файл (Batch)

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

@echo off
set SERVICE_NAME="1C:Enterprise 8.3 Server Agent"

echo Останавливаем службу 1С...
net stop %SERVICE_NAME%

echo Принудительно убиваем зависшие процессы...
taskkill /f /im rphost.exe
taskkill /f /im rmngr.exe
taskkill /f /im ragent.exe

echo Очищаем временные файлы и сеансовые данные...
for /d %%p in ("C:\Program Files\1cv8\srvinfo\reg_1541\*") do (
    if exist "%%p\snaccnt" (
        del /q /f "%%p\snaccnt\*.*"
    )
)

echo Запускаем службу 1С...
net start %SERVICE_NAME%

Рекомендации по обновлению

Проанализировав ситуацию, мы видим, что большинство проблем с сеансами в ветке 8.3.20 были признаны разработчиками как ошибки. Если технические возможности позволяют, настоятельно рекомендуем обновиться до версии 8.3.20.2159 или более поздних релизов веток 8.3.21/8.3.22. В этих сборках механизмы взаимодействия rmngr и rphost были существенно доработаны, а утечки памяти и зависания сеансов минимизированы.

Также хорошим советом будет пересмотреть стратегию бэкапов. Если вы используете MS SQL Server, современные средства СУБД позволяют делать полноценные резервные копии (Full Backup) без остановки служб 1С и без отключения пользователей, что полностью снимает остроту вопроса с зависшими сеансами.