Проблема не новая и время от времени обсуждается на всевозможных 1С-ных форумах. Самое простое и популярное решение — это перезагрузка сервера 1С. К сожалению, этот вариант не всегда допустим или крайне нежелателен. На такой случай существуют более деликатные решения.
Вот один из таких способов в виде краткой пошаговой инструкции:
1. С помощью консоли администрирования серверов 1С ищем проблемное фоновое задание в списке соединений (например, по времени начала его работы, сравнив с временем начала работы регламентированного задания в консоли заданий). Определяем рабочий процесс, в котором находится зависшее соединение.
2. Открываем свойства этого процесса и отмечаем его как неиспользуемый (если используется один единственный процесс, то предварительно необходимо создать новый рабочий процесс — для того, чтобы все активные соединения переподключились к нему). Запоминаем номер PID данного процесса.
3. Дожидаемся когда все текущие соединения переместятся из отключенного процесса в один из используемых. В конечном итоге в нашем процессе должны остаться только проблемные соединения, которые мы и хотим удалить.
4. На компьютере с сервером 1С с помощью диспетчера задач ищем соответствующий ему процесс rphost.exe по PID отключенного рабочего процесса и удаляем его.
5. На всякий случай можно удалить отключенный нами рабочий процесс 1С с пощью админ. консоли и, при необходимости, создать новый.
6. Готово. Можно войти в консоль заданий и проверить работоспособность регламентного задания.
Изменения:
23.04.2014 — внес корректировки согласно замечаниям в комментариям.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Это всё применимо к 8.1 и 8.2, а как применить на 8.3? Как известно там нельзя создать процесс вручную (Создаются автоматически на основе настроек сервера в кластере) и если он один, то и отключить нельзя… И не у всех имеется доп. ключ защиты чтобы использовать уровень отказоустойчивости например 1, чтобы перекинуть соединения на другой кластер…
Здесь уже где-то есть такая статья, только зачем искать процесс по ip-порту, когда в свойствах указан pid, для идентификации по pid кастомные диспетчеры не нужны
Спасибо, интересно не знал )
(1) dr.death,
Спасибо за комментарий! Полезная информация — на 8.3 еще с подобным не сталкивался. Изменю в свойствах публикации, что относится только к 8.1 и 8.2.
(2) konstruktiv,
Спасибо за комментарий! Подобную статью искал — не нашел. Видимо, плохо искал.
Что касается диспетчера задач — внесу корректировки в публикацию. По pid, конечно, удобнее и универсальнее получается.
Если не ошибаюсь, просто так активные соединения на другой процесс сами не перейдут.
Чтобы они подключились, их придется убить.
Убивать можно, если они не ведут активную работу.
Опять же если не ошибаюсь — проверить не на чем.
Спасибо за материал. Было бы интересно еще для 8.3
Спасибо, интересно.
Как на практике мигрируют сеансы на новый рабочий процесс?
Вроде где-то читал, что без прерывания работы перекидываются только пользователи с тонким клиентом, и то при условии что в данный момент нет операций с данными. Хотя возможно там речь была про миграцию сеансов на резервный кластер.
В общем интересует, убиваются ли соединения пользователей с отключаемого рабочего процесса? Или же происходит миграция, незаметная для пользователя без перезапуска клиентской части?
(9) Puk2,
Хороший вопрос.
Буквально сегодня выяснил из разговора со знакомым, что на 8.1 «мягкой» миграции из процесса в процесс не происходило — соединения были жестко привязаны к процессу. И действительно выход был только один — убивать процесс вместе со всеми его соединениями. Получается, что метод актуален в основном для 8.2. Хотя и в случае 8.1 (и 8.3?) позволит хотя бы минимизировать количество убитых соединений, если используется несколько рабочих процессов.
Что касается видов приложений — только что проверил, как они мигрируют. Погонял активные соединения между двумя процессами — успешно перебрасываются основные виды приложений — тонкий, толстый, веб-расширение. Не уверен, но по-моему COM-соединения с фоновыми заданиями тоже корректно переподключились (хотя возможно, что это уже новые создались). Конфигуратор, похоже не может переподключаться автоматом. Также обратил внимание, что соединения, имеющие активное соединение с СУБД не переподключаются пока соединение не завершится, что, наверное, логично.
хорошая статья. метод реально работает на 8.2
Спасибо! Взял материал на заметку…
Есть такая проблема, действительно. Обычно убивал в консоли все процессы и соединения, затем включал запрет старта регламентных заданий в свойствах баз. Тоже помогало. Через время блокировку старта рег. заданий снова разрешал.
на 8.3 работать не будет
А что мешает просто перезапустить службу? Вероятность того, что при этом отвалятся клиенты не сильно высока
(15) q1q1q1,
Возможно — не пробовал. А что произойдет с проблемными фоновыми заданиями в таком случае? Отвалятся?
(16)
Да, отвалятся. Следующий старт заданий произойдет по расписанию
(17) q1q1q1,
Спасибо, надо попробовать.
15. отваливаются и отваливается много, часто все.
Наконец-то найдено решение! Спасибо автору!
Странное решение…
Я на 8.3 делаю всё проще (и на 8.2 тоже самое работает):
1. Открываю «Администрирование серверов 1С Предприятия»
2. Выделяю нужную базу и захожу в «Свойства»
3. Запрещаю запуск регламентных заданий.
4. Прибиваю соединение этого «зависшего» фонового задания
5. … делаю что надо…
6. Разрешаю запуск рег. заданий
P.S. У нашего клиента есть такая «странная» конфа («1С:Подрядчик строительства 4.0. Управление финансами, редакция 3.0») у которой всегда есть одно «зависшее» фоновое задание.
Вот описанным выше методом мы его убиваем.
(21) EmpireSer,
Проблема в том, что бывают соединения, которые не удается удалить через консоль администрирования.
(22)
Если сеанса нет, а висят зависшие соединения — то твой способ то, что надо.
Хотя это, описанное тобой решение, универсально.
Если говорить не только про фоновые задания, то моя практика показала (хотя это только на 8.3 заметил), что на этом рабочем процессе (где нашлось «зависшее» соединение) все остальные соединения тоже «зависшие».
В моём случаи кластер просто запустил новый рабочий процесс и сам перевёл активные соединения на новый. В итоге получилось, что «зависший» рабочий процесс позволял удались сеанс, но соединения не «отваливались».
Вывод:
Я бы рекомендовал дополнить твой способ предварительной блокировкой запуска регламентных заданий. Так надёжнее.
(6) aspirator23, как раз таки если они ведут активную работу, то тогда соединения и сами перейдут на другой процесс.
А как это можно сделать на Linux? В нем нет «Консоли администрирования серверов 1с» .
(15) q1q1q1,
Конечно не высока. Где-то около 100% отвала всех подключений к серверу в течении пяти минут — пока сервер «сообразит», что ничего у него не работает.
(21) EmpireSer,
(13) erp-consul,
это не помогает зачастую, когда особенно запущенный случай. А все остальные и так прибиваются через консоль заданий.
(22)
если про сессии — как раз в консоли все удляется. Не удаляется процесс подключения к серверу. А не удаляется потому, что он активен и «висит» в ОС.
(24) konstruktiv,
речь именно про зависшие процессы, а не те, которые «ведут активную работу». Они и так удаляются, без плясок ))
(25) DjSpike,
суть не в консоли. Ищите процесс, и удаляйте его из задач ОС. Правда, отключатся и все сессии 1С, которые в данный момент «идут» через него.
(26) AlexO,
если про сессии — как раз в консоли все удляется. Не удаляется процесс подключения к серверу. А не удаляется потому, что он активен и «висит» в ОС.
К сожалению, не все удаляется. Об этом и речь. Сеанс/соединение в консоли удаляешь, из списка он исчезает, но после обновления списка снова отображается. При этом рабочий процесс «живой», с активными пользовательскими сеансами (хотя на живость, честно говоря, не проверял, пользователей не опрашивал).
(28)
это разные вещи в 1С.
Именно, что сеанс (сессия в терминологии 1С) удаляется из консоли, а соединение — нет.
да никуда он не исчезает, это недоработка 1с — она никак не сигнализирует, что с соединением что-то не так, и сервер не может удалить данное соединение (а не может удалить — потому что ОС считает его «живым», ведь оно активно как никогда).
И зависает именно на стороне 1С-сервера по различным причинам. И именно сервер же 1С не может его сбросить самостоятельно (исправить собственный «косяк»).
навряд ли все сессии будут живыми в подобном «зависшем» рабочем процессе — если сервер 1С не «понял» (и уже никак не «воспринимает») одно соединение из пула, то и остальные для него — скорей всего, не существуют уже.
Я таких ситуаций стараюсь не допускать, но в тестовых весь пул сессий в таком соединении — «мертвый».
(29) AlexO,
Несомненно, вещи разные. И в подобных случаях я наверняка пытался удалять и то и другое — поведение, по-моему, было одинаковое как в случае сеанса так и в случае соединения. Хотя сейчас уже не могу уверенно утверждать — давно не сталкивался с проблемой. Если будет возможность, постараюсь более тщательно исследовать вопрос.
Хм, интересно… Приму к сведению, спасибо.
(30)
С вас-то какой спрос, лучше б 1С подходило к разработке более ответственно, раз уж взялась за гуж 🙁
На 8.3 такое не прокатывает. Жаль.
Как удалить соединение пока не понятно.
Спасибо за мануал, однако это скорее костыль но не решение проблемы, которая судя по всему существует начиная с 8.3.4 и заканчивая 8.3.6
Добрый день, подскажите, почему в пункте 2, выпадающее меню не активно, пробовал и доменным админом и локальным. (запускаю с сервера на котором установлен сервер 1с)
Спасибо за заранее за ваши размыления на тему.
(35) Alex,
Добрый день!
Может быть, процесс уже не активен/выключен?
Простите, ничего толковее в голову не пришло 🙂
(36)
Да нет, все 5 процессов активны.
И даже тот, на котором сейчас работаю все сеансы.
Просто даже не понятно в какую сторону капать, обычно такое из за прав доступа, но куда уж больше чем локальный админ?
Спасибо большущее!!!
Помог!
Добавь в статью как добавлять рабочий процесс, без этой инфы результат не получить!
у меня в консоли сервера не доступно изменять на неиспользуемое и создать новый рабочий процесс не дает
(40) AlexeyK1, Статья старая. До 8.3 можно было вручную управлять рабочими процессами. Смотри в (34) фокус для 8.3 с интервалом перезапуска.
По-идее, должно работать. Нормальные сеансы должны перенестись на новые рабочие процессы, а «мертвые» 1С убить не сможет, как и процессы их породившие. Останется убить их средствами ОС. Насколько я понимаю, свойство кластера «Принудительно завершать проблемные процессы» призвана автоматизировать это дело.
Т.е. в идеале, если настроить интервал перезапуска и эту галку, то 1С будет автоматом убивать процессы с зависшими после переноса сеансами.
(40) AlexeyK1, да у нас тоже 8.3. В комментах вычитал про интервал. Тогда создается 2 рабочий процесс и он сам делает перевод активных сеансов. Единственное, когда убиваешь процесс, без перезагрузки их количество не уменьшается, хоть они и не активны.
(42) Xershi, (41) herfis, (40) AlexeyK1,
Статья актуальна только для 8.2 (см. Платформа в разделе Характеристики справа).
А программно можно получить по, скажем номеру сеанса у app-шника spid скуля?
Кто нибудь решал такую задачу?
(34) единственный рабочий способ для 8.3 из предложенных
(43) сегодня нужно было убить фоновое задание обновления ПТИ. Убил но в соединениях осталось висеть. Второй процесс не создался, время не пришло. Опять наткнулся на вашу статью. Но минут через 15 фоновое задание либо само завершилось, либо 1С его убило. Платформа 8.3.13. В итоге рассосалось само собой. Так бы быстрее было бы агента рестартануть, но нужно было сделать для одной базы, а на сервере их две.
Просто завершить службу зависшего RPHOST для зависшего задания. (найти по id) в рабочем процессе.
Есть вероятность, что пользователи даже не вылетят, по крайней мере неработающие прямо сейчас.
(46) В 8.3 можно настроить параметры рабочего сервера:
Указать параметр Количество ИБ на процесс = 1
Тогда для каждой базы будет свой процесс, который можно завершить — при необходимости — без рестарта агента.
Сеансы других баз при этом не пострадают.
Спасибо за актуальный комментарий про 8.3
Как раз на днях процесс намертво завис.
(47)Также была проблема с зависшим рабочим процессом. Удаление процесса rphost из Диспетчера задач по номеру PID не помогло, в Консоли кластера процесс так и остался. Перезагрузка службы сервера не помогла.
Решение:
— посмотреть порт зависшего процесса
— в диспетчере задач если не включена колонка CommandLine
— найти процесс rmngr с нужным портом и завершить дерево процессов
После данных действий зависший рабочий процесс с консоли ушёл
Есть еще более простой способ без завершения процессов и перезагрузки сервера. Действует и на 8.3.
Нужно завершить все сеансы данной базы, удалить и заново добавить базу в список. И все!
(51) а журнал регистрации не отвалится?
(34) В какой книжке это написано? Что бы знать, а то по названию окошек, ничерта не понятно, какое на что реально влияет и как себя ведет