1с сервер недоступен не отвечает завершается аварийно или порт занят другим приложением line 1089
Как отключить пользователей программно в клиент-серверном варианте работы 1С 8.2.
Спасибо, то что нужно.
Но есть пару непоняток (для меня):
я заменил "Сервер" на "ИмяСервера" в строке
РабПроц = Коннектор.ConnectWorkingProcess(Сервер + ":" + СтрЗаменить(Порт, Символы.НПП, ""));
и в COMОбъекте Соединение нет значения UserName, т.е. не могу проверить на ИмяПользователя(). Но и в Сеанс, и в Соединение есть SessionID, пришлось выкручиваться через него (получать в Сеанс и проверять в Соединение). UserName только у меня отсутствует? Платформа 8.2.11.236.
Платформа 1С:Предприятие 8.2 (8.2.17.153).
РабПроц.Disconnect(Соединение);
по причине:
Типы не совпадают (1)
Как не пробовал, одно и тоже :(
Вариант кода следующий:
По синтакс-помощнику GetInfoBaseConnections получает массив описаний соединений информационной базы. А в описании соединения нет свойства UserName. Оно есть в свойствах соединения.
Осталось только разобраться как получить не описание соединений, а сами соединения. :D
Хм. Соединения заработали только когда прописал (обгуглившись по самое ну погоди):
ИнформационнаяБаза2 = РабПроц.CreateInfoBaseInfo();
ИнформационнаяБаза2.Name = ИмяБазы;
Соединения = РабПроц.GetInfoBaseConnections(ИнформационнаяБаза2);
При этом проверять запущенные приложения нужно не по Соединение.Application, а по Соединение.AppID. Плюс не мешало бы добавить проверку не только backgroundjob, designer, а и comconsole - а то выкинет и только что аутентифицированное COM-соединение.
Все вышесказанное абсолютно не претендует на истину - пробуйте на свой страх и риск. :D
(3) Спасибо за развитие, честно дальше не копал. По "Сервер" на "ИмяСервера" - это я код не подправил :)
"Плюс не мешало бы добавить проверку не только backgroundjob, designer, а и comconsole - а то выкинет и только что аутентифицированное COM-соединение. " я показал лишь пример, дальше можно расширять как угодно :) моей целью было НЕ убивать текущее фоновое задание и НЕ закрывать конфигуратор, в котором я могу что-то не сохранить :) да и вообще сама идея мочить конфигуратор - ужас.
(3) V_V_V, Всё верно. Тоже дошёл до этого обчитавшись хелпа. Дело в том, что если делать GetInfoBaseConnections через агента сервера (а не через рабочий процесс), то мы получаем на выходе тип "Описание соединения", а не "Соединение". У него действительно нет UserName и вместо AppID есть Applications.
ИМХО, чтобы не убить своё собственное соединение лучше использовать проверку на SessionID (ConnID), который есть и в соединении (сеансе). Получить SessionID (ConnID) текущего (своего) подключения можно через НомерСеансаИнформационнойБазы() (НомерСоединенияИнформационнойБазы()).
(9) Если ничего не путаю, то именно через SessionID я и выкрутился. Кажется об этом речь в моем первом посте шла (1).
Как давно это было. Год прошел. :)
(10) V_V_V, Ну, некоторые темы не стареют. Для меня как раз проблемой было как раз узнать ID текущего сеанса, чтобы сравнить с SesionID. Может кому нибудь тоже поможет.
(7) столкнулся с такой ошибкой. Дело в том, что строка подключения к базе данных содержало порт. Таким образом при получении имени сервера, возвращается не имя сервера("127.0.0.1"), а имя сервера + порт ("127.0.0.1:1689").
Заменил строку - все заработало:
//ИмяСервера = Лев(ПодстрокаПоиска, Найти(ПодстрокаПоиска, """") - 1); //для стандартного порта (1541)
ИмяСервера = Лев(ПодстрокаПоиска, Найти(ПодстрокаПоиска, """") - 6); //для не стандартного порта (7) artur.antipin,
Заменил строку - все заработало:
//ИмяСервера = Лев(ПодстрокаПоиска, Найти(ПодстрокаПоиска, """") - 1); //для стандартного порта (1541)
ИмяСервера = Лев(ПодстрокаПоиска, Найти(ПодстрокаПоиска, """") - 6); //для не стандартного порта (7) artur.antipin,
Вот не уверен, что это правильно.
Вообще говоря, то ИмяСервера (включая порт), которое мы получаем таким образом, это адрес кластера 1с, на котором крутится эта база. Если порт стандартный, то он совпадает с именем сервера (читай агента сервера). Если порты не стандартные - то они разные.
Так вот. Если вы просто обрежете порт из адреса кластера, то получите обращение по стандартному порту, т.е. 1541, и скорее всего, попадете на другой сервер, не тот, на котором крутится данная база.
Вот в связи с этим вопрос: можно ли как то узнать полный адрес агента сервера, на котором крутится эта база?
(36) для администрирования нужен порт не 1541, а 1540. Соответственно, если у вас неск. серверов, то использовать порт из строки подключения не корректно. Нужно хранить порт отдельно или получать из консоли.
Вместо -
РабПроц = Коннектор.ConnectWorkingProcess(Имяервера + ":" + СтрЗаменить(Порт, Символы.НПП, ""));
надо -
РабПроц = Коннектор.ConnectWorkingProcess("tcp://" + Процесс.HostName + ":" + Формат(Процесс.MainPort, "ЧГ=0"));
Автору - спасибо! Использовал для отключения юзеров при ночной выгрузке базы
вот обобщенный (рабочий!) вариант:
Если Найти(СтрокаСоединенияИнформационнойБазы(), "Srvr") > 0 Тогда
// серверный вариант
Поиск1 = Найти(СтрокаСоединенияИнформационнойБазы(), "Srvr """) - 1);
// теперь ищем имя базы
Поиск1 = Найти(СтрокаСоединенияИнформационнойБазы(), "Ref """) - 1);
Иначе
// для других способов подключения алгоритм не актуален
Возврат;
КонецЕсли;
Коннектор = Новый COMОбъект("v82.COMConnector");
Агент = Коннектор.ConnectAgent(ИмяСервера);
Кластеры = Агент.GetClusters();
Для каждого Кластер из Кластеры Цикл
АдминистраторКластера = "Имя администратора кластера";
ПарольКластера = "Пароль администратора кластера";
//Агент.Authenticate(Кластер, АдминистраторКластера, ПарольКластера);
Агент.Authenticate(Кластер,,);
Процессы = Агент.GetWorkingProcesses(Кластер);
Для каждого Процесс из Процессы Цикл
Порт = Процесс.MainPort;
// теперь есть адрес и порт для подключения к рабочему процессу
РабПроц = Коннектор.ConnectWorkingProcess(ИмяСервера + ":" + СтрЗаменить(Порт, Символы.НПП, ""));
РабПроц.AddAuthentication("admin", "pass");
Базы = Агент.GetInfoBases(Кластер);
Для каждого База из Базы Цикл
Если База.Name = ИмяБазы Тогда
ИнформационнаяБаза = База;
Прервать;
КонецЕсли;
КонецЦикла;
Если ИнформационнаяБаза = "" Тогда
// база не найдена
КонецЕсли;
Сеансы = Агент.GetInfoBaseSessions(Кластер, ИнформационнаяБаза);
Для каждого Сеанс из Сеансы Цикл
ИнформационнаяБаза2 = РабПроц.CreateInfoBaseInfo();
ИнформационнаяБаза2.Name = ИмяБазы;
СоединенияБазы = РабПроц.GetInfoBaseConnections(ИнформационнаяБаза2);
// Разорвать соединения клиентских приложений.
Для Каждого Соединение Из СоединенияБазы Цикл
Если нРег(Соединение.AppID) = "backgroundjob" ИЛИ нРег(Соединение.AppID) = "comconsole" Тогда
Продолжить;
КонецЕсли;
Если Соединение.UserName = ИмяПользователя() Тогда
// это текущий пользователь
Продолжить;
КонецЕсли;
РабПроц.Disconnect(Соединение);
КонецЦикла;
КонецЦикла;
КонецЦикла;
Предупреждение("Завершается работа. ", 5);
ЗавершитьРаботуСистемы(Ложь);
запускаю из батника
C:\"Program Files"\1cv82\8.2.13.219\bin\1cv8.exe ENTERPRISE /sИмяСервера\ИмяБазы /nПользователь /pПароль /wa- /DisableStartupMessages /RunModeOrdinaryApplication /ExecuteShutdownusers.epf
Доброго времени суток друзья, столкнулся с проблемой, не могу разобраться с ее решением. Обо всем по порядку.
Не так давно, мы начали переход на 1С БП 3.0 и все что на ней основано, по сравнению с 2.0 тормозить она стала раз в 5 больше, базы открывались от 2 до 5 минут! Решение пришло быстро, MS SQL Server.
Так как для меня это первый опыт его настройки, начал я тренироваться в виртуальной машине Hyper-V, все работало более менее, пока я не загрузил туда БД сельхоз отдела, примерно через 2 - 3 часа работы сервер перестает работать, базы не подключается, даже напрямую на этом же сервере. В локальной сети выходит ошибка "1541 descr = сервер не доступен (не отвечает, завершается аварийно или порт занят другим приложением". Сначала я грешил на сетевую карту, потом на брандмауер (его отключение тоже не помогло), и вот вчера я взял физический сервер, все настроил установил, перенес базы и буквально час назад та же беда! Все драйвера обновлены, мощности сервера должно хватать (Xeon X5606 2.13 Ghz/24Gb RAM DDR3 1333/LAN 1Gb) у сети топология "Звезда". Последнее на что грешу то что сервер не включен в домен Active Directory, но тогда почему и на самом сервере база отваливается?
Кратко о ПО:
1С Предприятие 8.3.8.2088
MS SQL Server 2014 SP1
Windows Server 2008R2
Буду рад любому совету.
Дополнено:
Аналогичная проблема проявляется на Debian. С одной базой УТ10 работает нормально. При переносе старой БД (бухгалтерия) с файлового варианта на SQL (postgres) периодически раз в 1-2 недели базы становятся недоступными до перезапуска службы srv1cv83. Есть ощущение что чем больше баз переносится тем меньше срок работы до перезапуска, так при переносе 5 БД срок работы был 2-3 дня.
К одной базе УТ10 доступ осуществляется локально (на одной машине), при добавлении других баз работа с ними начинается через клиентов по сети, но в момент сбоя базы недоступны ни в каком виде до перезапуска службы srv1cv83.
В технологическом журнале из подозрительного можно выделить только следующее:
есть 1с сервер 8.3.2.
установлен на Ubuntu Server 12.04 LTS.
замечено, что клиенты иногда от него отключаются с ошибкой: Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением).
на самом сервере телнет до порта работает.
памяти свободной полно, процессор простаивает, LA
вопросы:
1 как определить причину?
2 как грамотно мониторить процесс зависания и перезапускать его?
И что вы подразумеваете под "перезапускать его"? Весь менеджер кластера?
У 1С почти многие проблемы оказываются недоработками разработчиков и фиксятся через общение с техподдержкой, долгими обещаниями доработки, и собственно доработкой. А по другому, только либо какие то кардинальные перенастройки ОС/модернизации (что впрочем может решить одну проблему и создать три других), либо собственноручное экспериментирование, попытки понять причины повисаний или изобретение собственного обходного пути, типа создание внешнего мониторящего процесса, который и будет что-то там перезапускать, если пропадает ответ от серверной части 1с.
"перезапускать его" - например посылать ему kill с нужным ключем.
ну или перезапускать исключительно его, а не весь кластер. с кластером то проблем нет - /etc/init.d/srv1c83 restart )))
почитал ссылку, спасибо. боль :(
буду тогда 1 раз ночью ребутать) пока лучшего решения не найду)
mrpsycho: На самом деле ребут 1 раз в день - костыль конечно, но очень уж зараза универсальный. И не только на win-системах приходилось встречать. Сейчас сделаешь, проблема решается - и решение так и остается как постоянное, т.к. нет ничего более постоянного, чем временное =)))))
Работали на 8.2.13.205 - все было хорошо. Все-таки решили обновить платформу на 8.2.19.68. Обновили. В результате - в локальной сети (несколько подсетей) все работает. А из других городов вываливает ошибку: server_addr=tcp://sql1:1560 descr=Сервер недоступен (Не отвечает, завершается аварийно или порт занят другим приложением) . ну и дальше бла,бла,бла . Путем несложных танцев с бубном обнаружилось: толстый клиент запускается, а если тонкий клиент - вываливается с вышеописанной ошибкой. Дальнейшие танцы выявили следующую закономерность: при скорости порядка 60кБит - еще работает, а вот на 40кБит - ошибка. Скорость соединения давилась искусственно.
думаю более стабильный канал интернета поможет решить эту проблему. как трассировка к серверу проходит, сколько пакетов теряет?
Поймал аналогичную проблему именно на релизе 8.2.19.68. Как победить непонятно. Для себя решил переведя работу тонкого клиента через веб сервер.
такое ощущение, что разработчики решили, что сейчас у вех ОЧЕНЬ быстрый тырнет и задавили таймауты. ну ведь же заявлено, что "тонкий" может на медленных каналах работать :( и, самое главное - он работал .
Я думаю дело не в скорости, у нас между филиалами скорость вполне приличная, а все равно не работает. Через web сервер при этом работает нормально.
там проблема не в скорости тырнета. а как производити запуск? после тестов получил что если запускать через common/1cestart вылетает если запускаю через 8.2.19.68/bin/ то всё работает..
А через диспетчер задач можно командную строку восстановить и поперебирать параметры на предмет глючного?
в очереднйо раз правило подтвердилось! Ни в коем случае нельзя работать на последних релизах. П,С, "Стальная Крыса" - хорошая книга :)
Было такое, долго разбирался. В итоге помогло: 1. Отключаем все компоненты IPv6, кроме интерфейса замыкания на себя (loopback interface), путём внесения в реестр HKLM:SYSTEMCurrentControlSetservicesTCPIP6Parameters -Name DisabledComponents -PropertyType DWord -Value 0xffffffff 2. Останавливаем вспомогательную службу IP.
поскриптум: после некоторой работы на 8.2.18.109 (помним, что вернулись из 8.2.19) обнаружилось падение 1С при нажатии на кнопку выбора из справочника с "ошибкой SQL" (текст приводить нет смысла) наблюдалось такое поведение не во всех формах (. ) где был реквизит такого типа справочника. помогло только удаление формы выбора этого справочника и создания новой, точно такой же. зы. даже выгрузка в dt и загрузка не решили этой проблемы. во как .
Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Планируется в версии 8.3.21
В версии 8.3.21 мы сделали ряд доработок, призванных сделать взаимодействие системы с пользователем более удобным для пользователя.
Помощь пользователю при ошибке при входе в систему
Если ошибка произошла при входе в систему, пользователю можно будет показать дополнительную информацию, которая сможет помочь ему решить возникшую проблему:
Ссылка на ресурс с информацией (например, на сайт, где описаны способы решения возникшей проблемы)
Ошибки, возникающие при входе в систему – одни из самых непростых в обработке. Такие ошибки, в частности, могут возникать из-за недоступности сервера 1С, и, значит, в этот момент с сервера нельзя получить данные о том, какую информацию показать пользователю. Поэтому описанную выше информацию можно записать для каждой базы в файл списка баз *.v8i – при неудачном входе в систему информация будет считана из этого файла (при доступности файла) и показана пользователю.
Есть варианты работы, когда файлы *.v8i недоступны – работа в облаке, удалённая работа и т.п. Поэтому эту информацию также можно настроить через стандартную обработку «Управление настройками отображения ошибок» (параметры «Текст помощи» и «Навигационная ссылка помощи») и сохранить в инфобазе. Если с клиента уже был ранее осуществлен успешный вход в систему – эти параметры считываются с сервера и кэшируется на клиенте.
Если клиент успешно связался с сервером и считал актуальные значения параметров «Текст помощи» и «Навигационная ссылка помощи», но далее при работе системы возникли проблемы при соединении с сервером – в диалоге попытки повторного подключения будут использованы последние считанные значения параметров.
Обратите внимание! Информация, записанная в файле *.v8i, и настройки параметров «Текст помощи» и «Навигационная ссылка помощи» - независимы друг от друга. В случае, если доступен файл *.v8i, но недоступен сервер 1С и на клиенте нет закэшированных значений параметров «Текст помощи» и «Навигационная ссылка помощи» – пользователю будет показана информация из файла *.v8i, в противном случае – информация из параметров «Текст помощи» и «Навигационная ссылка помощи».
Настройки подключения к базе
В файл списка баз (*.v8i) в свойства базы добавляется параметры:
StartupErrorHelpText (строка) – текст, отображаемый в диалоге ошибки до начала сеанса или диалоге попытки повторного подключения
StartupErrorHelpURL (строка) – ссылка на ресурс с информацией
Тонкий клиент
Проверьте сетевое соединение
Проверьте, что параметры подключения указаны верно
Если проблема возникла уже после начала работы с системой - на форме повтора попытки соединения с сервером отображаемый текст будет таким же, как и на таблице вверху, а полный текст можно посмотреть, нажав на ссылку «Показать подробности…».
Веб-клиент
При невозможности связаться с веб-сервером в браузере будет отображена страница с информацией об ошибке подключения, текстом, заданный в настройках, и текстом, полученным из запроса на адрес сервиса информации (т.е. фактически с той же информацией, что и в тонком клиенте):
Это будет работать при соблюдении нескольких условий:
На веб-сервер уже был осуществлен удачный вход из браузера (для кэширования на клиенте страницы, показывающей информацию об ошибке)
Браузер должен поддерживать технологию service-workers
Про сервер обработки ошибок при запуске
Выше мы упомянули параметр «Адрес сервиса обработки ошибок при запуске».
Если этот параметр задан, то при ошибках запуска по этому адресу клиент 1С сделает запрос дополнительной информации. А по этому адресу можно настроить веб-сервер, который будет отдавать более подробную информацию о текущей ситуации - информировать пользователей при возникновении неожиданных аварийных ситуаций и / или недоступности сервера и т.п. Например, можно отобразить пользователю текст “Мы уже работаем над проблемой. Работа сервера возобновится после 14:00”.
Для поддержки это сценария можно реализовывать совсем простой вариант: просто положить JSON-файл в папку и настроить веб-сервер (Apache, nginx, IIS) на отдачу этого файла. При возникновении проблем на сервере можно вписать в этот файл необходимый текст (userMessage) и настроить время, до которого этот текст будет отображаться на форме (в нашем примере – до 14:00).
Можно реализовывать и более сложные сценарии – например, отправлять информацию об ошибках при входе в систему на внутренний сервис техподдержки организации.
Отчет об ошибке
При формировании отчета об аварийном завершении добавляется возможность показа окна “О программе”.
Читайте также: