Пользователь проводит документ — и 1С закрывает подключение с сообщением: «Сеанс работы завершён администратором». Всё, что он не успел записать в базу, пропадает.
Остановите повторные входы. Запишите точное время ошибки и узнайте, кого отключило: одного сотрудника, отдел или всех пользователей базы. Само сообщение не доказывает, что администратор вручную завершил сеанс.
Так 1С сообщает о нескольких разных событиях. Среди них — ручное отключение, регламентное задание, тайм-аут, потеря связи и остановка rphost. Фирма «1С» не публиковала документа, который однозначно связывает эту фразу с одной причиной. Искать виновника по тексту окна бесполезно. Нужное событие находят по времени в нескольких журналах.
До проверки серверной части сделайте резервную копию базы. Клиент-серверную базу копируйте средствами СУБД. Разворачивайте копию отдельно, а не поверх рабочей базы.
Сначала определите масштаб сбоя
Число отключённых пользователей сразу сужает поиск. Позвоните двум сотрудникам из того же офиса и попросите открыть базу. Перезапускать кластер для такой проверки не нужно.
Если пострадал один человек, проверяйте его сеанс, компьютер и сетевой маршрут. Одновременное отключение нескольких пользователей ведёт к общей части системы: rphost, СУБД или каналу связи.
| Что увидели | Что произошло рядом | Первая проверка | Куда идти дальше |
|---|---|---|---|
| Сообщение получил один пользователь | Администратор работал со списком сеансов | Сверить пользователя и время в списке сеансов | Проверить ручное завершение |
| Отключилась заданная группа | В это время выполнялось служебное задание | Проверить расписание и условия задания | Искать механизм блокировки пользователей |
| Ошибка появилась после простоя | Пользователь долго не обращался к серверу | Проверить параметры неактивных сеансов | Сверить тайм-аут и фактическое время простоя |
| Несколько пользователей отключились одновременно | Пропала связь, остановился процесс или возникла ошибка СУБД | Сопоставить время в серверных журналах | Проверить сеть, rphost и СУБД |
| Отключается один компьютер без общего сбоя | Меняется Wi‑Fi, VPN или режим питания | Подключить компьютер по кабелю и проверить сон | Диагностировать рабочее место |
| Перед сообщением окно 1С зависло | Отдельный сеанс перестал отвечать | Найти его в списке подключений | Завершать только подтверждённый проблемный сеанс |
Первый вывод уже есть: пока вы не знаете масштаб сбоя, открывать все журналы подряд рано. Сначала определите границу проблемы.
Если 1С зависает перед разрывом, пройдите сетевую ветку отдельным порядком. Здесь важен не текст сообщения, а состояние TCP-соединения между клиентом и сервером.
Зафиксируйте данные до повторного входа
Запишите пользователя, компьютер, информационную базу и время с точностью до минуты. Уточните последнее действие: вход в базу, проведение документа, построение отчёта или ожидание без работы.
Фраза «ошибка была после обеда» почти бесполезна. За несколько часов в журналах накопятся разные события, и вы не отличите нужное от соседних.
Не просите пользователя заново открыть документ и повторить операцию. Если соединение рвёт задание или сеть, вы получите ещё один обрыв. Пользователь снова потеряет несохранённые изменения.
Проверьте активные сеансы
Откройте в Конфигураторе «Администрирование → Сеансы». По материалу 1C Expert, список содержит имя пользователя, компьютер и время начала подключения. Поля «Приложение» и «Основное приложение» отделяют пользовательский клиент от служебного процесса.
Найдите все подключения нужного пользователя. Сверьте компьютер и время начала каждого сеанса с записью об ошибке.
Если старого подключения уже нет, вы подтвердили только его завершение. Список не расскажет, кто отправил команду и по какой причине сервер её выполнил.
Не отключайте сеансы типа «Администрирование». 1C Expert предупреждает: такое действие может нарушить работу сервера.
Перед принудительным отключением обычного сеанса предупредите пользователя. Команда разрывает соединение и не записывает открытый документ в базу.
Зависшее подключение отключайте по порядку для одного неотвечающего сеанса. Перезапуск сервера из-за одного пользователя оборвёт работу всех остальных.
Найдите событие в журнале регистрации
Откройте «Администрирование → Поддержка и обслуживание → Журнал регистрации». Этот путь указан в материале Mngb о проверке действий пользователей.
Выберите короткий интервал вокруг записанного времени. Добавьте отбор по пользователю и событиям «Сеанс» и «Транзакция». Если данных мало, включите уровни «Ошибка» и «Предупреждение».
Посмотрите, что пользователь делал прямо перед отключением. Журнал привязывает события к времени и объектам, поэтому по нему можно восстановить последовательность работы.
Соседнее событие ещё не означает причину. Сначала найдите последнее действие пользователя. Затем сравните его время с расписанием заданий и серверными журналами.
Доступные публикации не подтверждают, что журнал регистрации всегда показывает фамилию администратора, который завершил сеанс. Не обещайте такую точность пользователю или руководителю.
Отключённый журнал не хранит прошлую цепочку событий. На это прямо указывает материал Mngb. Тогда остаются технологический журнал, журналы СУБД и Windows, а также сведения от администратора.
Не записывайте в отчёте об инциденте: «работа сеанса завершена администратором 1С». Это пересказ окна, а не результат проверки. Зафиксируйте время, пользователя, состояние подключения и события сервера рядом с обрывом.
Проверьте регламентные задания и тайм-ауты
Администратор мог не трогать сеанс. Регламентное задание конфигурации способно проверять подключения и отключать пользователей по заданному условию. Такой механизм описывают 1C Expert и Infostart.
Проверьте задания, связанные с обновлением, обменом, резервным копированием и блокировкой входа. Сравните время их запуска с моментом ошибки.
Отдельно изучите код завершения работы, если компания добавляла собственное задание контроля пользователей. Запишите расписание и условие отключения. Настройки пока не меняйте: сначала подтвердите совпадение.
Затем проверьте время жизни неактивного сеанса в кластере. По материалу 1C Expert, сервер разрывает соединение после заданного периода простоя.
Слово «неактивный» здесь легко вводит в заблуждение. Пользователь может ждать длинный отчёт, но 1С не всегда учитывает такую работу как активность. На эту особенность указывает компания «Интеграция».
Если обрыв повторяется через одинаковый интервал, сравните его с тайм-аутом. Одного совпадения мало. Проверьте настройку кластера и убедитесь, что в тот же момент сервер не записал другую ошибку.
Если ручного завершения нет, сопоставьте журналы сервера и сети
Перед этой проверкой снимите резервную копию средствами СУБД. Не разворачивайте её поверх рабочей базы. «Тестирование и исправление» тоже не запускайте: оно меняет данные и не помогает установить причину сетевого разрыва.
Откройте технологический журнал за короткий интервал вокруг ошибки. Компания «Интеграция» связывает события EXCP и SDBL перед обрывом с серверной веткой диагностики.
Но один код диагноза не даёт. Проверьте контекст события, процесс, информационную базу и повторяемость.
На том же интервале откройте журналы СУБД. Запрос «сеанс завершен администратором 1С SQL» часто уводит администратора к поиску ошибки SQL. Клиентское сообщение такой связи не подтверждает. Основанием станет совпадение базы и времени.
| Признак | Вероятная причина | Как проверить | Что сделать после подтверждения |
|---|---|---|---|
| Ошибка только на одном ноутбуке | Wi‑Fi, VPN, антивирус или сон компьютера | Повторить подключение по кабелю, проверить VPN и журнал питания | Исправить маршрут или параметры рабочего места |
| Одновременно отключился отдел | Сбой общего канала или сетевого оборудования | Проверить потери пакетов с нескольких компьютеров | Искать общий участок сети |
| Разрывы идут только через VPN | Фрагментация или нестабильный туннель | Сравнить работу через локальную сеть и VPN | Проверить MTU и настройки туннеля |
| На сервере растёт потребление памяти | Рабочий процесс упёрся в память | Сопоставить процесс rphost и время отключений | Разобрать нагрузку конкретного процесса |
Перед обрывом появился EXCP | Исключение в серверном процессе | Открыть контекст события технологического журнала | Устранить указанную серверную причину |
Перед обрывом появился SDBL | Ошибка обращения к СУБД | Сверить базу и время с журналом СУБД | Проверить запрос, блокировку или состояние СУБД |
| Пользователь отключается после простоя | Тайм-аут неактивного сеанса или сон компьютера | Сравнить интервалы и настройки | Исправить подтверждённый параметр |
После сообщения исчез отдельный rphost | Сбой рабочего процесса | Проверить журналы ОС и кластера | Работать с конкретным процессом |
Совпадение времени в журнале регистрации, технологическом журнале и журнале СУБД весит больше текста в пользовательском окне.
Как проверить сетевую ветку
Компания «Интеграция» считает потери пакетов выше 1–2% на проводном соединении признаком сетевой проблемы. Это ориентир интегратора, а не требование фирмы «1С».
Проверьте одинаковый маршрут с компьютера пользователя и соседнего рабочего места. Потери только у одного сотрудника ведут к его кабелю, сетевому адаптеру или защитному ПО.
Для VPN компания «Интеграция» рекомендует проверить MTU 1400. Не устанавливайте это значение во всех туннелях подряд. Сначала подтвердите фрагментацию на том маршруте, где возникает обрыв.
Wi‑Fi зависит от помех соседних точек доступа и других устройств. Подключите компьютер кабелем и повторите проверку. Если по кабелю 1С работает, серверную часть можно временно отложить и заняться радиоканалом.
Проверьте режим сна компьютера. По материалу компании «Интеграция», автоматический переход в сон тоже разрывает подключение.
Антивирус способен вмешаться в сетевой обмен и работу процессов платформы. Начните с журнала блокировок. Отключать защиту на сервере без подтверждённой причины не нужно.
Как проверить rphost, не останавливая кластер
Сервер 1С распределяет подключения между рабочими процессами rphost. Поэтому сбой одного процесса иногда отключает лишь часть пользователей.
Через средства администрирования кластера сопоставьте оборванные сеансы с рабочим процессом. Последовательность действий есть в материале про управление сеансами и рабочими процессами.
Проверьте журнал ОС, технологический журнал и потребление памяти этого процесса. Ищите его состояние в момент обрыва. После автоматического запуска картина уже изменится.
Параметр «Максимальный объём памяти рабочих процессов» не меняют наугад. Компания «Интеграция» указывает, что значение 0 снимает ограничение. Само по себе оно не подтверждает нехватку памяти и не подсказывает подходящий лимит.
Если события ведут к одному rphost, работайте с ним. Перед перезапуском посмотрите, какие сеансы он обслуживает, и выберите нужный уровень. Порядок описан в инструкции по перезапуску отдельных компонентов 1С.
После запуска откройте контрольную базу и выполните прикладную операцию. Работающая служба ещё не доказывает, что сотрудники снова могут проводить документы и строить отчёты.
Чего не делать при единичном отключении
Не перезапускайте весь сервер после одного сообщения. Так вы сотрёте часть сведений о состоянии процесса и отключите тех, кто продолжал работать.
Не завершайте подряд все подключения с одинаковым именем. Один пользователь мог открыть несколько клиентов или запустить служебную операцию.
Не трогайте сеанс типа «Администрирование». По предупреждению 1C Expert, его завершение может нарушить работу серверных механизмов.
Не меняйте за один раз тайм-аут, ограничения rphost и параметры VPN. Если ошибка исчезнет, вы не узнаете, какая настройка повлияла на неё.
Не запускайте «Тестирование и исправление» из-за разрыва соединения. Операция меняет данные базы, но сетевой сбой не диагностирует.
Не восстанавливайте резервную копию поверх рабочей базы. Проверяйте её на другом сервере, в отдельном экземпляре СУБД или в другой базе.
Если не помогло
Передавайте проблему дальше, когда отключения повторяются, а журналы не указывают на одну причину. Соберите точное время событий, имена пользователей, технологический журнал, журнал СУБД и сведения о сетевом маршруте.
Связку платформы, СУБД и серверных процессов можно отдать на диагностику повторяющегося аварийного отключения. По одному сообщению нельзя назвать срок работ или объём данных, который удастся восстановить.
Другие ветки проверки собраны в навигаторе по сбоям базы и серверной части. Откройте его, если вместе с разрывом появилась другая ошибка сервера.
Чтобы не повторилось
Сохраните фильтр журнала регистрации по пользователю, сеансу и времени. Настройте срок хранения так, чтобы записи доживали до разбора инцидента.
Проверьте расписание заданий, которые блокируют вход или завершают подключения. У каждого задания должны быть записаны владелец, условие запуска и допустимое окно работы.
Настройте резервное копирование базы 1С и регулярно разворачивайте копию отдельно. Файл на диске ещё не доказывает, что из него получится вернуть базу.
При следующем сообщении пройдите пять шагов:
- Запишите пользователя, компьютер и точное время.
- Выясните, отключился один человек или несколько.
- Проверьте список сеансов без массового завершения.
- Отфильтруйте журнал регистрации по времени и пользователю.
- Сверьте момент с заданиями, тайм-аутами, технологическим журналом и журналом СУБД.
Фраза «завершён администратором» открывает расследование, но не называет причину. Если следа ручного отключения нет, переходите к заданиям, серверным процессам и сети.
Кто завершил сеанс, если администратор ничего не делал?
Подключение мог разорвать серверный механизм, регламентное задание, тайм-аут или сбой связи. Сопоставьте время сообщения с журналами и расписанием заданий.
Где посмотреть, кто и когда снял сеанс?
Начните со списка сеансов и журнала регистрации с отбором по пользователю и времени. Журнал не всегда показывает конкретного человека, отправившего команду.
Может ли регламентное задание отключить пользователя?
Да, конфигурация может содержать задание, которое проверяет активные подключения и завершает их по условию. Проверьте расписание и код такого задания.
Связана ли ошибка с SQL Server или PostgreSQL?
Само сообщение этого не доказывает. Ищите совпавшее по времени событие в технологическом журнале и журнале СУБД.
Нужно ли перезапускать сервер 1С?
При единичном отключении нет. Сначала найдите затронутый сеанс или рабочий процесс и проверьте его журналы.
Пропадут ли данные открытого документа?
Изменения, которые пользователь не записал в базу, могут пропасть. Перед принудительным завершением предупредите пользователя.