1с сервер не удаляются сеансы пользователей
Обновлено: 06.07.2024
Время от времени у меня возникает ощущение, что с какой-то проблемой никто, кроме меня, не сталкивался. То ли остальные не считают это проблемой и не видят смысла обсуждать, то ли секретную инструкцию вовремя прочитали и тем более молчат. В общем, никого вокруг проблема не беспокоит, хотя надо бы. А мне и спросить не у кого.
Именно такая ситуация возникла, когда я несколько лет назад занялся администрированием серверов 1С. А конкретно проблема заключалась в потерянных сеансах пользователей, мешающих обслуживать базы на сервере. Коллеги в таком случае просто открывали консоль администрирования и жали мышкой на красный крестик, да и то лишь когда им позвонят и попросят удалить сеансы.
Меня такой подход совершенно не устраивал, тем более что приближались новогодние каникулы. Бухгалтера, как водится, собирались ударно поработать чуть ли не со 2 января, а я вовсе не горел желанием чего-то там удалять мышкой по крестику, отвлекаясь от личных дел.
Средства, предусмотренные на этот случай разработчиками платформы (Конфигуратор – Администрирование – Параметры ИБ – Время засыпания пассивного сеанса, Время завершения спящего сеанса), почему-то работали как хотели и не гарантировали результат. Возможно, они до сих пор точно так же халтурят. Давно не проверял за ненадобностью.
Когда я стал искать в интернете готовый рецепт, довольно легко нашел, как удалять соединения, но не сеансы. Недоумение переросло в беспокойство. У меня-то проблем с соединениями не было, у меня проблема с сеансами! У меня что, платформа какая-то не такая, как у всех?
Но все же через синтакс-помощник и путем экспериментов решение было найдено достаточно быстро. Первый вариант внешней обработки был готов к нужному моменту, и результат стоил того. С тех пор накопился реальный опыт применения, обработка неспешно обросла опциями и в своем нынешнем виде прикреплена к этой статье. А здесь хотелось бы поговорить о том, как этим средством пользоваться.
Алгоритм, предлагаемый платформой 1С для получения сведений о сеансах, а заодно и удаления, в схематичном виде выглядит так:
Здесь АдминКластера и ПарольАдминКластера – это логин и пароль администратора кластера серверов 1С. На практике их обычно можно не задавать. Значения по умолчанию – пустая строка.
Посмотрите еще раз на процедуру Сеансы(). В свойствах объекта Сеанс содержится все, что нужно, чтобы отличить одни сеансы от других. Ну, кроме того, чего в платформе все равно нет. А нет там хоть какого-то признака потерянных сеансов.
С остальным все просто. Например, на вопрос, каким приложением создан сеанс, отвечает свойство Сеанс.AppID. Оно может иметь значения: "1CV8" – толстый клиент, "1CV8C" – тонкий клиент, "WebClient" – веб-клиент, "Designer" – конфигуратор, "BackgroundJob" – фоновое задание.
Есть еще свойства, значения которых сообщаются только для толстого клиента, конфигуратора и фонового задания. Это номер процесса (Сеанс.Process.PID) и номер соединения (Сеанс.Connection.ConnID). Учитывая все большее распространение тонкого клиента, эти сведения приходится признать бесполезными. Скорее всего, таким способом вам не удастся выяснить связь конкретного процесса rphost.exe с какой-либо базой. Кстати, в консоли администрирования мы наблюдаем ту же картину.
А еще жаль, что в длинном списке свойств нет явного указания на тот самый сеанс, в котором работает наша программа. Ведь его ни в коем случае нельзя удалять. Значит, придется самим организовать паспортный контроль. Например, вот так:
У объекта ТекущийСеанс есть еще свойство НомерСоединения, но надежность этого признака может зависеть от того, когда объекту присваивается значение – в начале работы или непосредственно перед проверкой. Ну, и замечание, сделанное выше, тоже надо иметь в виду.
Впрочем, даже показанный здесь набор условий выглядит избыточным. Наверняка хватило бы имени базы и номера сеанса, ведь остальные свойства – по сути атрибуты сочетания база + сеанс. Но, сдается мне, лучше воздержаться от такой оптимизации. Никто ведь не гарантировал корректность паспортных данных у потерянных сеансов и невозможность случайных совпадений.
Лучше обратите внимание на то, что проверка имени пользователя должна учитывать подвох, возникающий, например, при работе с пустой базой или при запуске фоновых заданий в отсутствие активных пользователей .
Ну, а если кому-то необходимо посмотреть или удалить соединения, то вместо процедуры Сеансы() нужно вызвать процедуру Соединения(), показанную ниже, но тогда еще потребуются логин и пароль администратора информационной базы:
Разбирая весьма неочевидную последовательность действий, описанную в этой процедуре, можно догадаться, почему в свое время на каком-то форуме нашлась подсказка именно насчет соединений. Для прохождения этого квеста нужен опытный проводник, а с сеансами можно и самому разобраться.
Впрочем, для меня до сих пор остается загадкой, зачем кому-то может потребоваться удалять соединения. Они и сами исправно отваливаются. Лично мне они никогда не мешали.
К тому же, сеанс может быть без соединения, если не нуждается в нем в данный момент. Если сеанс не обращается к кластеру (то есть пользователь бездействует), соединение ему не назначается. Так что для нас объект охоты – сеансы, а не соединения.
Ну так вот, что, собственно, мы собираемся удалять, если у сеансов нет никакого специально предусмотренного флажка вроде ЭтоПотерянный? Как отличить хороших от плохих?
А никак. Нет ведь флажка. Это и есть правильный ответ. Но меня он совершенно не устраивал.
Поэтому моя обработка удаляет сеансы, которые выглядят потерянными. Первый кандидат на это звание – заснувшие сеансы, созданные тонким или толстым клиентом. Просто с другими клиентами я до сих пор не сталкивался, так что пусть пока будет так.
И пусть такие сеансы удаляются автоматически с некоторой периодичностью, например, раз в минуту, что совсем не трудно реализовать. А также при нажатии кнопки, что еще проще.
И вот тут возникает пара совершенно справедливых вопросов.
А во-вторых, как быть с сеансами, которым не спится? Как ни заглянешь в консоль, у них последняя активность вот только что была. Звонишь пользователю – нет никого. Пингуешь компьютер – опять никого. А сеанс все трудится, занят непонятно чем.
В ответ обработка обзавелась парой самых важных опций.
Во-первых, предусмотрен период бездействия, то есть время, в течение которого автоматическое удаление не выполняется. Границы периода задаются с учетом обстоятельств.
Например, если у вас лицензия на 50 подключений, в консоли стабильно наблюдаются 45-48 реальных сеансов, а денег на еще одну лицензию не дают, значит бездействуем только в обед и немного до и после него. Здесь главная задача – обеспечить резерв подключений, чему пользователи будут только рады. Их гораздо больше раздражает невозможность подключиться к базе, когда очень надо.
Если пользователей мало, лицензий гарантированно хватает, к тому же пользователи славятся дружным уходом домой в конце рабочего дня, тогда можно никого не беспокоить весь рабочий день с небольшим запасом.
Кроме того, параметр «Время засыпания пассивного сеанса» все-таки чаще работает, чем не работает. Можно увеличить его с традиционных 20 минут до часа, и это сильно сократит количество жалоб.
Вторая важная опция – возможность удалять сеансы, созданные вчера или еще раньше, но не позднее заданного количества часов назад. Последнее условие позволяет не обрушивать ровно в полночь всю работу. По умолчанию задано 12 часов в расчете на тех, кто приступил к работе после обеда.
Не стоит легкомысленно относиться к этому параметру. Мало ли кто засиделся за компом, нервно смотрит на часы и хочет домой. Кофе давно допит, отчетность вот-вот будет сдана, а тут бац – и карета превращается в тыкву. Тут уж не сомневайтесь – утром придет злая мачеха, и вы узнаете о себе много такого, о чем, в принципе, догадывались.
Необходимо сделать важное замечание, связанное с сеансом самой обработки. Очевидно, что ее выполнение не должно зависеть от пользователей. Самый простой способ добиться этого – специально создать пустую базу и запускать обработку поверх нее. Разумеется, в этом случае база с обработкой займет лишний сеанс.
Сеанс, в котором запущена сама обработка, игнорируется. Но тут есть пара нюансов. С одной стороны, ничто не мешает запускать несколько экземпляров обработки с разными настройками, причем каждый в своем сеансе. С другой стороны, при перезапуске сервера сеанс базы с обработкой может восстановиться, но стать недоступным для управления, то есть по сути потерянным.
Из этих и не только этих соображений предусмотрена возможность указывать базы, исключенные из проверки, а для быстрого заполнения списков добавлены галочки «Проверять все базы» и «кроме этой базы». По умолчанию база с обработкой игнорируется.
Со временем появилась еще пара опций, требующихся редко, даже очень редко, но иногда полезных.
Во-первых, иногда коллеги-админы забывают закрыть конфигуратор после обслуживания базы на сервере. Пришлось предусмотреть возможность удалять такие сеансы. Но это только возможность, а вовсе не обязанность!
Только не забудьте, что если вы решили с помощью обработки расчищать дорогу для бэкапа, а бэкап баз 1С делаете запуском конфигуратора из командной строки, то придется как-то развести по времени удаление чужих сеансов конфигуратора и запуск своих. Тут период бездействия будет как раз кстати.
Ну, а во-вторых, один раз за свою не слишком долгую практику я наблюдал потерянные сеансы фоновых заданий. Уж не помню, что там за катаклизм приключился, но сеансы дружно повисли в консоли. Ладно, пусть будет и такая галочка. Опять же только возможность, а не обязанность.
Поскольку здесь обсуждались индивидуальные настройки процесса удаления для каждого конкретного сервера, возникает вопрос, не обзавелась ли моя обработка, как любая уважающая себя программа, файлом конфигурации? Да, есть такой. Назовем его файлом параметров, чтобы не путаться в терминах. Но об этом ниже.
В командной строке приложений 1С предусмотрены два очень полезных ключика. Ну, не считая других, разумеется. Это /Execute и /C.
Благодаря им установка и первый запуск моей обработки на сервере выглядят так:
1. Копирую на сервер комплект файлов:
v8i-файл для ее запуска
cmd-файл для регистрации библиотеки comcntr.dll
2. Создаю пустую базу. Пусть будет emptybase, к примеру.
3. Регистрирую на сервере библиотеку comcntr.dll, если это до сих пор еще не сделано.
4. В меню стартера 1С добавляю готовый v8i-файл запуска базы с обработкой, хотя это можно и не делать.
Где взять файл обработки, сказано в конце статьи.
Файл для регистрации comcntr.dll сделан из файла RegMSC.cmd. В нем просто заменено имя библиотеки. Ну, и запускать его надо в подкаталоге bin каталога нужной версии платформы.
Файл для запуска базы с обработкой выглядит примерно так:
Уверен, вы знаете, как им пользоваться. Самое интересное написано в последней строке.
Ну и наконец, файл параметров. Здесь он называется setup.txt. Одновременно он служит руководством по написанию таких файлов. Вот реальный пример:
Тут интересны два момента:
1) НомерСоединенияИнформационнойБазы() - Получает номер текущего соединения с информационной базой.
2) ПолучитьСоединенияИнформационнойБазы() - Получает массив описаний соединений с текущей информационной базой.
И всё, третий сеанс им не даёт открыть.
У нас ещё есть пользователи, которым можно любое количество сеансов.
Всем остальным было сделано при открытии нового сеанса просто сбрасывали все ранние. Так решилась проблема зависших сеансов, когда пользователи не могли зайти в документ, который они открывали зависшими сеансами.
Время от времени у меня возникает ощущение, что с какой-то проблемой никто, кроме меня, не сталкивался. То ли остальные не считают это проблемой и не видят смысла обсуждать, то ли секретную инструкцию вовремя прочитали и тем более молчат. В общем, никого вокруг проблема не беспокоит, хотя надо бы. А мне и спросить не у кого.
Именно такая ситуация возникла, когда я несколько лет назад занялся администрированием серверов 1С. А конкретно проблема заключалась в потерянных сеансах пользователей, мешающих обслуживать базы на сервере. Коллеги в таком случае просто открывали консоль администрирования и жали мышкой на красный крестик, да и то лишь когда им позвонят и попросят удалить сеансы.
Меня такой подход совершенно не устраивал, тем более что приближались новогодние каникулы. Бухгалтера, как водится, собирались ударно поработать чуть ли не со 2 января, а я вовсе не горел желанием чего-то там удалять мышкой по крестику, отвлекаясь от личных дел.
Средства, предусмотренные на этот случай разработчиками платформы (Конфигуратор – Администрирование – Параметры ИБ – Время засыпания пассивного сеанса, Время завершения спящего сеанса), почему-то работали как хотели и не гарантировали результат. Возможно, они до сих пор точно так же халтурят. Давно не проверял за ненадобностью.
Когда я стал искать в интернете готовый рецепт, довольно легко нашел, как удалять соединения, но не сеансы. Недоумение переросло в беспокойство. У меня-то проблем с соединениями не было, у меня проблема с сеансами! У меня что, платформа какая-то не такая, как у всех?
Но все же через синтакс-помощник и путем экспериментов решение было найдено достаточно быстро. Первый вариант внешней обработки был готов к нужному моменту, и результат стоил того. С тех пор накопился реальный опыт применения, обработка неспешно обросла опциями и в своем нынешнем виде прикреплена к этой статье. А здесь хотелось бы поговорить о том, как этим средством пользоваться.
Алгоритм, предлагаемый платформой 1С для получения сведений о сеансах, а заодно и удаления, в схематичном виде выглядит так:
Здесь АдминКластера и ПарольАдминКластера – это логин и пароль администратора кластера серверов 1С. На практике их обычно можно не задавать. Значения по умолчанию – пустая строка.
Посмотрите еще раз на процедуру Сеансы(). В свойствах объекта Сеанс содержится все, что нужно, чтобы отличить одни сеансы от других. Ну, кроме того, чего в платформе все равно нет. А нет там хоть какого-то признака потерянных сеансов.
С остальным все просто. Например, на вопрос, каким приложением создан сеанс, отвечает свойство Сеанс.AppID. Оно может иметь значения: "1CV8" – толстый клиент, "1CV8C" – тонкий клиент, "WebClient" – веб-клиент, "Designer" – конфигуратор, "BackgroundJob" – фоновое задание.
Есть еще свойства, значения которых сообщаются только для толстого клиента, конфигуратора и фонового задания. Это номер процесса (Сеанс.Process.PID) и номер соединения (Сеанс.Connection.ConnID). Учитывая все большее распространение тонкого клиента, эти сведения приходится признать бесполезными. Скорее всего, таким способом вам не удастся выяснить связь конкретного процесса rphost.exe с какой-либо базой. Кстати, в консоли администрирования мы наблюдаем ту же картину.
А еще жаль, что в длинном списке свойств нет явного указания на тот самый сеанс, в котором работает наша программа. Ведь его ни в коем случае нельзя удалять. Значит, придется самим организовать паспортный контроль. Например, вот так:
У объекта ТекущийСеанс есть еще свойство НомерСоединения, но надежность этого признака может зависеть от того, когда объекту присваивается значение – в начале работы или непосредственно перед проверкой. Ну, и замечание, сделанное выше, тоже надо иметь в виду.
Впрочем, даже показанный здесь набор условий выглядит избыточным. Наверняка хватило бы имени базы и номера сеанса, ведь остальные свойства – по сути атрибуты сочетания база + сеанс. Но, сдается мне, лучше воздержаться от такой оптимизации. Никто ведь не гарантировал корректность паспортных данных у потерянных сеансов и невозможность случайных совпадений.
Лучше обратите внимание на то, что проверка имени пользователя должна учитывать подвох, возникающий, например, при работе с пустой базой или при запуске фоновых заданий в отсутствие активных пользователей .
Ну, а если кому-то необходимо посмотреть или удалить соединения, то вместо процедуры Сеансы() нужно вызвать процедуру Соединения(), показанную ниже, но тогда еще потребуются логин и пароль администратора информационной базы:
Разбирая весьма неочевидную последовательность действий, описанную в этой процедуре, можно догадаться, почему в свое время на каком-то форуме нашлась подсказка именно насчет соединений. Для прохождения этого квеста нужен опытный проводник, а с сеансами можно и самому разобраться.
Впрочем, для меня до сих пор остается загадкой, зачем кому-то может потребоваться удалять соединения. Они и сами исправно отваливаются. Лично мне они никогда не мешали.
К тому же, сеанс может быть без соединения, если не нуждается в нем в данный момент. Если сеанс не обращается к кластеру (то есть пользователь бездействует), соединение ему не назначается. Так что для нас объект охоты – сеансы, а не соединения.
Ну так вот, что, собственно, мы собираемся удалять, если у сеансов нет никакого специально предусмотренного флажка вроде ЭтоПотерянный? Как отличить хороших от плохих?
А никак. Нет ведь флажка. Это и есть правильный ответ. Но меня он совершенно не устраивал.
Поэтому моя обработка удаляет сеансы, которые выглядят потерянными. Первый кандидат на это звание – заснувшие сеансы, созданные тонким или толстым клиентом. Просто с другими клиентами я до сих пор не сталкивался, так что пусть пока будет так.
И пусть такие сеансы удаляются автоматически с некоторой периодичностью, например, раз в минуту, что совсем не трудно реализовать. А также при нажатии кнопки, что еще проще.
И вот тут возникает пара совершенно справедливых вопросов.
А во-вторых, как быть с сеансами, которым не спится? Как ни заглянешь в консоль, у них последняя активность вот только что была. Звонишь пользователю – нет никого. Пингуешь компьютер – опять никого. А сеанс все трудится, занят непонятно чем.
В ответ обработка обзавелась парой самых важных опций.
Во-первых, предусмотрен период бездействия, то есть время, в течение которого автоматическое удаление не выполняется. Границы периода задаются с учетом обстоятельств.
Например, если у вас лицензия на 50 подключений, в консоли стабильно наблюдаются 45-48 реальных сеансов, а денег на еще одну лицензию не дают, значит бездействуем только в обед и немного до и после него. Здесь главная задача – обеспечить резерв подключений, чему пользователи будут только рады. Их гораздо больше раздражает невозможность подключиться к базе, когда очень надо.
Если пользователей мало, лицензий гарантированно хватает, к тому же пользователи славятся дружным уходом домой в конце рабочего дня, тогда можно никого не беспокоить весь рабочий день с небольшим запасом.
Кроме того, параметр «Время засыпания пассивного сеанса» все-таки чаще работает, чем не работает. Можно увеличить его с традиционных 20 минут до часа, и это сильно сократит количество жалоб.
Вторая важная опция – возможность удалять сеансы, созданные вчера или еще раньше, но не позднее заданного количества часов назад. Последнее условие позволяет не обрушивать ровно в полночь всю работу. По умолчанию задано 12 часов в расчете на тех, кто приступил к работе после обеда.
Не стоит легкомысленно относиться к этому параметру. Мало ли кто засиделся за компом, нервно смотрит на часы и хочет домой. Кофе давно допит, отчетность вот-вот будет сдана, а тут бац – и карета превращается в тыкву. Тут уж не сомневайтесь – утром придет злая мачеха, и вы узнаете о себе много такого, о чем, в принципе, догадывались.
Необходимо сделать важное замечание, связанное с сеансом самой обработки. Очевидно, что ее выполнение не должно зависеть от пользователей. Самый простой способ добиться этого – специально создать пустую базу и запускать обработку поверх нее. Разумеется, в этом случае база с обработкой займет лишний сеанс.
Сеанс, в котором запущена сама обработка, игнорируется. Но тут есть пара нюансов. С одной стороны, ничто не мешает запускать несколько экземпляров обработки с разными настройками, причем каждый в своем сеансе. С другой стороны, при перезапуске сервера сеанс базы с обработкой может восстановиться, но стать недоступным для управления, то есть по сути потерянным.
Из этих и не только этих соображений предусмотрена возможность указывать базы, исключенные из проверки, а для быстрого заполнения списков добавлены галочки «Проверять все базы» и «кроме этой базы». По умолчанию база с обработкой игнорируется.
Со временем появилась еще пара опций, требующихся редко, даже очень редко, но иногда полезных.
Во-первых, иногда коллеги-админы забывают закрыть конфигуратор после обслуживания базы на сервере. Пришлось предусмотреть возможность удалять такие сеансы. Но это только возможность, а вовсе не обязанность!
Только не забудьте, что если вы решили с помощью обработки расчищать дорогу для бэкапа, а бэкап баз 1С делаете запуском конфигуратора из командной строки, то придется как-то развести по времени удаление чужих сеансов конфигуратора и запуск своих. Тут период бездействия будет как раз кстати.
Ну, а во-вторых, один раз за свою не слишком долгую практику я наблюдал потерянные сеансы фоновых заданий. Уж не помню, что там за катаклизм приключился, но сеансы дружно повисли в консоли. Ладно, пусть будет и такая галочка. Опять же только возможность, а не обязанность.
Поскольку здесь обсуждались индивидуальные настройки процесса удаления для каждого конкретного сервера, возникает вопрос, не обзавелась ли моя обработка, как любая уважающая себя программа, файлом конфигурации? Да, есть такой. Назовем его файлом параметров, чтобы не путаться в терминах. Но об этом ниже.
В командной строке приложений 1С предусмотрены два очень полезных ключика. Ну, не считая других, разумеется. Это /Execute и /C.
Благодаря им установка и первый запуск моей обработки на сервере выглядят так:
1. Копирую на сервер комплект файлов:
v8i-файл для ее запуска
cmd-файл для регистрации библиотеки comcntr.dll
2. Создаю пустую базу. Пусть будет emptybase, к примеру.
3. Регистрирую на сервере библиотеку comcntr.dll, если это до сих пор еще не сделано.
4. В меню стартера 1С добавляю готовый v8i-файл запуска базы с обработкой, хотя это можно и не делать.
Где взять файл обработки, сказано в конце статьи.
Файл для регистрации comcntr.dll сделан из файла RegMSC.cmd. В нем просто заменено имя библиотеки. Ну, и запускать его надо в подкаталоге bin каталога нужной версии платформы.
Файл для запуска базы с обработкой выглядит примерно так:
Уверен, вы знаете, как им пользоваться. Самое интересное написано в последней строке.
Ну и наконец, файл параметров. Здесь он называется setup.txt. Одновременно он служит руководством по написанию таких файлов. Вот реальный пример:
Тут интересны два момента:
1) НомерСоединенияИнформационнойБазы() - Получает номер текущего соединения с информационной базой.
2) ПолучитьСоединенияИнформационнойБазы() - Получает массив описаний соединений с текущей информационной базой.
И всё, третий сеанс им не даёт открыть.
У нас ещё есть пользователи, которым можно любое количество сеансов.
Всем остальным было сделано при открытии нового сеанса просто сбрасывали все ранние. Так решилась проблема зависших сеансов, когда пользователи не могли зайти в документ, который они открывали зависшими сеансами.
Завершение сеанса пользователя в 1С может потребоваться в следующих случаях:
- обновление информационной базы;
- проведение восстановления работы на сервере или профилактических работ;
- зависшие сеансы пользователей, которые препятствуют повторному входу;
- добавление нового объекта метаданных в конфигурацию.
В данной инструкции мы расскажем, как правильно завершить сеанс пользователя и покажем несколько способов в зависимости от требований.
Эти и другие работы мы выполняем в рамках ИТ-аутсорсинга.
Важно запомнить, что прежде чем завершать сеанс пользователя, требуется предупредить пользователя об этом, так как возможна потеря данных.
Закрытие сеансов из конфигуратора
При внесении изменений в структуру базы и обновлении конфигурации в динамическом режиме может появиться ошибка, которая не предоставит нам возможности продолжить выполнение обновления до тех пор, пока не завершим сеанс пользователя.
Рисунок 1 - Ошибка активных сеансов
Для завершения сеанса требуется:
- Нажать кнопку Завершить сеансы и повторить.
- Дождаться окна реструктуризации базы.
- Нажать Принять.
Завершение сеансов пользователя из программы 1С
В основном все продукты фирмы 1С 8 версии имеют механизм, позволяющий удаленно завершить работу пользователя и обеспечить администратору монопольный доступ к базе. Это обработка Блокировка соединений с информационной базой. Найти её можно по следующему адресу: Администрирование => обслуживание => блокировка работы пользователей.
Рисунок 2 - Блокировка работы пользователей
Рисунок 3 - Подтверждение блокировки сеанса
Удаление пользователей из RDP
Удалить пользователя из терминального сервера можно при наличии определенных прав на это действие. Возможно завершить работу из стандартного диспетчера задач, но простое прерывание сеанса - не очень правильно. Второй вариант - использование диспетчера задач, удаленное подключение к сеансу и корректное завершение с помощью выхода из программы. Это, конечно, долгий способ и нет гарантий, что пока выполняется выход одного пользователя, не будет подключен еще пользователь, который запустит программу.
Для сервера 1С и обладая правами Администратора для кластера серверов 1С, необходимо:
- Запустить консоль администрирования сервера 1С.
- В ветке Информационные базы, найти базу, в которой будем завершать работу пользователя.
- Открыв её, зайти в ветку Сеансы.
- Щелкнув правой кнопкой мыши по имени пользователя, выбрать пункт Удалить.
Рисунок 4 - Удаление в консоли администрирования
Часто бывает, что при работе в серверном режиме зависшие сеансы пользователей не видны средствами платформы, их можно удалить только через консоль.
Перезагрузка сервера
Нельзя и упустить такой момент, что одним из способов завершения сеанса пользователей является банальная перезагрузка сервера, выполнить её можно, если все вышеуказанные способы не сработали, но такое случается редко. Безусловно, требуется пользователей предупредить, чтобы они успели сохранить файлы и завершить работу с программами.
Ко мне обратился один из пользователей обновлятора со следующей проблемой:
Есть клиент, у которого вечно пропадают лицензии 1с, пользователи запускают несколько сеансов и работают, но лицензий не хватает. Точнее хватало бы, если бы использовалось по одной лицензии. В свое время я намучился с этим у себя на демо сервере, где пользователи запускают веб-сеансы и не закрывают их как положено, в результате куча новых сеансов и как следствие, нехватка лицензий.И он предложил добавить в обновлятор следующую функциональность:
Периодически проверяем все сеансы на сервере и если какой-то из сеансов не использовался в течении N-минут, то завершаем его, освобождая таким образом лицензии.Решение
1. Перейдите в обновляторе на закладку "Скрипты":
2. Здесь выберите тип скрипта "Пакетный" и базу, в которой требуется периодически завершать неиспользуемые сеансы на сервере 1с:
3. Далее нажмите пункт "обновлятор", далее "Методы", далее "Завершение неиспользуемых сеансов":
4. Откроется диалог со следующими параметрами:
Пробежимся по его настройкам.
а. Прежде всего мы задаём типы сеансов на сервере 1с, которые нужно обрабатывать. По умолчанию, отмечены только 1CV8 и 1CV8C - толстый и тонкий клиенты соответственно. Если вы хотите, чтобы обрабатывались и другие типы сеансов, отметьте их галками.
б. Выбор между "в базе" и "в кластере". Нужно понимать, что скрипт всегда запускается для какой-то конкретной базы, которую мы выбрали в настройках. Если таких баз 10 скрипт запускается 10 раз для каждой из этих баз. Если выбран пункт "в базе", то обрабатываются только сеансы базы, для которой сейчас выполняется скрипт. Если же выбран пункт "в кластере", то обрабатываются все сеансы кластера, в который входит база.
в. Пункт "неактивные более Х минут". Сеансы, которые неактивны более X минут будут завершаться принудительно. Внимание. Для реализации этой опции обновлятор ориентируется на последнюю активность сеанса, которую нам возвращает сервер. Это значение можно увидеть в оснастке кластера в колонке сеанса "Последняя активность". К сожалению, в большинстве случаев (видимо фоновое поведение клиента) эта колонка обновляется кластером даже если пользователь не работает напрямую в базе. Я не нашёл других способов узнавать именно пользовательскую активность в сеансе.
г. Пункт "спящие". Если поставить эту галку, то сеансы, у которых установлен признак Hybernate (спящий), будут завершаться принудительно.
д. Пункт "дубли". Если поставить эту галку, то сеансы запущенные в одной и той же базе, с одного и того же компьютера, под одним и тем же пользователем будут считаться дублями. Из всех дублей будет оставляться только самый старый сеанс (запущенный первым из всех), а все остальные будут завершаться принудительно.
В нашем случае мы хотим, чтобы завершались все сеансы кластера, в который входит база, если:
- сеанс является толстым или тонким клиентом
- сеанс неактивен более 10 минут
- сеанс заснул
Настройки диалога будут такими:
Нажимаем OK и в текст скрипта вставляется следующая команда:
Если вы программист или опытный администратор, то думаю без труда понимаете какой параметр здесь за что отвечает.
Снимаем (если они стоят) все галки, они нам в этом скрипте ни к чему:
Теперь можете смело экспериментировать, чтобы убедиться что скрипт делает то, что вам нужно. Для этого создавайте необходимые условия для завершения сеансов и нажимайте кнопку "Запустить".
Предположим, что всё в полном порядке.
Осталось сохранить этот скрипт в планировщик, чтобы он запускался по расписанию.
Нажимаем кнопку "Сохранить":
В открывшемся диалоге зададим путь и имя (сделайте его осмысленным) скрипта. Из галок обязательно поставим "Закрывать обновлятор после работы скрипта" и "Настроить однократный запуск скрипта через планировщик Windows":
Нажмём "ОК" и укажем авторизацию пользователя, под которым нужно выполнять скрипт:
Снова нажмём ОК. Готово, скрипт добавился в планировщик заданий.
Теперь перейдём в планировщик заданий Windows и уже в нём настроим нужную нам периодичность запуска:
Откроем задание на редактирование и на закладке "Триггеры" укажем, что хотим выполнять задачу ежедневно каждые 15 минут:
Замечание
Если планируется достаточно частое выполнение этого скрипта, я советую вынести эту задачу в отдельный (портативный установленный) экземпляр обновлятора.
Нужно понимать, что технически запуск скрипта равносилен запуску обновлятора для выполнения определенных задач. А такие запуски в рамках одного экземпляра программы выстраиваются в очередь. И если у вас ночью запустилось пакетное обновление баз на 8 часов, то пока все эти обновления не отработают, никакие скрипты запущены не будут.
В целом под небольшие и часто повторяемые задачи я советую выделить отдельный экземпляр программы.
Также отдельно обращаю внимание на то, что вы можете сохранить несколько скриптов с разными параметрами контроля сеансов для разных баз/групп баз/кластеров.
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Читайте также: