Добрый день.
В ближайшие 2 года стал сталкиваться с ситуацией, когда не работает серверная отладка (ниже опишу подробнее). К сожалению, сам решения не нашел. Потому надеюсь тут докопаться до истины.
Исходные данные*:
Управление торговлей, редакция 11 (11.4.13.209)
Платформа 8.3.22.2239.
Ключ -debug в запуске службы агент сервера 1С запущен. (а иначе бы и не было даже видно серверные сеансы)
* Подобная ситуация происходила с разными конфигурациями и платформами. Но для чистоты эксперимента приведу текущий пример.
Картина при входе в меню отладки в конфигураторе до начала отладки:
Серверные сеансы видны при указании поиска предметов отладки на сервере.
Нажимаем на кнопку начала отладки. Клиентский сеанс подключается сам, серверный видно в списке доступных, но сам не подключается. Уже первая странность.
Пробуем подключить вручную. Успешно. Серверный сеанс подключен.
А по факту не работает. Точки отладки на серверных процедурах не останавливаются. Попытки "Шагнуть в" в серверные процедуры тоже не работают.
Из наблюдений. Ранее эта же база работала на платформе 8.3.18.1289 и находилась на одном сервере с другой базой идентичной конфигурации. Отладка работала и там, и там. Далее был переезд базы на другое железо, после чего началась проблема (а у базы, что осталась на месте, все продолжает нормально работать). т.е. все указывает на некие сетевые настройки.
Что было сделано/опробовано:
1) Полностью отключали брандмауэр на обеих сторонах.
2) Проверяли порты 1560-1591 телнетом.
3) Перезапускали службу агент сервера.
4) Перезагружали сам сервер.
5) Пытались прописывать путь подключения к базе и поиска предметов отладки как через ИП адрес, так и через сетевое имя. А также через вымышленное сетевое и прописание его в файл hosts компьютере, откуда ведется отладка (терминальный сервер)
6) Ставили галочку автоматического подключения к клиентским и внешним соединениями (а вдруг)
Во всех случаях, когда сталкивался с подобной проблемой, у клиента крупная сетевая структура с большим количеством подсетей и впн.
т.к. железо обслуживается, как правило, другими людьми, то диалог с системными администраторами выходит примерно такого характера: "Что именно не так? Вы скажите, что именно и как надо настроить, мы исправим". А вот что от них требовать и как тестировать, не ясно.
Буду рад любым советам/рекомендациям, что попробовать.
п.с. у одного клиента эту ситуацию я застал в процессе ее появления. Был открыт конфигуратор с тестовой копией базы. Из него отладка нормально работала. В параллель запустил рабочую базу, а там отладка не работает. Несколько раз пытался пускать из обоих конфигураторов. Работала только в тестовой копии. А вот когда я закрыл конфигуратор тестовой копии и зашел в него заново, то уже и там перестало работать. Опять же, указывает на сетевые настройки. И, судя по ситуации, настройки эти применяются при запуске конфигуратора, а не при попытках обращения к отладке.
п.п.с. Возможно ли такое, что из-за настроек сети телнет на нужный порт проходит, а работата с серверным сеансом блокируется на одной из сторон или даже посередине?
В ближайшие 2 года стал сталкиваться с ситуацией, когда не работает серверная отладка (ниже опишу подробнее). К сожалению, сам решения не нашел. Потому надеюсь тут докопаться до истины.
Исходные данные*:
Управление торговлей, редакция 11 (11.4.13.209)
Платформа 8.3.22.2239.
Ключ -debug в запуске службы агент сервера 1С запущен. (а иначе бы и не было даже видно серверные сеансы)
* Подобная ситуация происходила с разными конфигурациями и платформами. Но для чистоты эксперимента приведу текущий пример.
Картина при входе в меню отладки в конфигураторе до начала отладки:
Серверные сеансы видны при указании поиска предметов отладки на сервере.
Нажимаем на кнопку начала отладки. Клиентский сеанс подключается сам, серверный видно в списке доступных, но сам не подключается. Уже первая странность.
Пробуем подключить вручную. Успешно. Серверный сеанс подключен.
А по факту не работает. Точки отладки на серверных процедурах не останавливаются. Попытки "Шагнуть в" в серверные процедуры тоже не работают.
Из наблюдений. Ранее эта же база работала на платформе 8.3.18.1289 и находилась на одном сервере с другой базой идентичной конфигурации. Отладка работала и там, и там. Далее был переезд базы на другое железо, после чего началась проблема (а у базы, что осталась на месте, все продолжает нормально работать). т.е. все указывает на некие сетевые настройки.
Что было сделано/опробовано:
1) Полностью отключали брандмауэр на обеих сторонах.
2) Проверяли порты 1560-1591 телнетом.
3) Перезапускали службу агент сервера.
4) Перезагружали сам сервер.
5) Пытались прописывать путь подключения к базе и поиска предметов отладки как через ИП адрес, так и через сетевое имя. А также через вымышленное сетевое и прописание его в файл hosts компьютере, откуда ведется отладка (терминальный сервер)
6) Ставили галочку автоматического подключения к клиентским и внешним соединениями (а вдруг)
Во всех случаях, когда сталкивался с подобной проблемой, у клиента крупная сетевая структура с большим количеством подсетей и впн.
т.к. железо обслуживается, как правило, другими людьми, то диалог с системными администраторами выходит примерно такого характера: "Что именно не так? Вы скажите, что именно и как надо настроить, мы исправим". А вот что от них требовать и как тестировать, не ясно.
Буду рад любым советам/рекомендациям, что попробовать.
п.с. у одного клиента эту ситуацию я застал в процессе ее появления. Был открыт конфигуратор с тестовой копией базы. Из него отладка нормально работала. В параллель запустил рабочую базу, а там отладка не работает. Несколько раз пытался пускать из обоих конфигураторов. Работала только в тестовой копии. А вот когда я закрыл конфигуратор тестовой копии и зашел в него заново, то уже и там перестало работать. Опять же, указывает на сетевые настройки. И, судя по ситуации, настройки эти применяются при запуске конфигуратора, а не при попытках обращения к отладке.
п.п.с. Возможно ли такое, что из-за настроек сети телнет на нужный порт проходит, а работата с серверным сеансом блокируется на одной из сторон или даже посередине?
Прикрепленные файлы:
По теме из базы знаний
- Менеджер по работе с Google календарем
- Разные хм... неожиданности при работе с УТ 11 и платформой
- Многопоточный CI-контур для 1С c Packer, Vagrant и Jenkins. Часть 1. Описание системы и обзор инструментария
- Правила обмена больше не нужны
- Интеграция 1С с маркетплейсами из одного окна: Озон, ВБ, Яндекс, Сбер, Али, ЛаМода - для УНФ, УТ, КА, ERP
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) Оно! Для меня стало новостью, что при серверной отладке не клиентская машина к серверу подключается, а наоборот. В приведенном примере сперва сняли полностью брандмауэр на стороне клиента (помогло), затем уже включили обратно с правилом разрешения на вход (исходящее не создавали) по портам 1560-1591 и до кучи 1540, 1541
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот