Ночью есть необходимость запускать скрипт для выполнение которого необходимо перевести базу в монопольный режим. Т.е. чтобы в базе никого не было. В 8.2 это было банально: стоп сервис, старт сервис и пользователи не закрывшие 1с все отваливались. Заодно утечки памяти по рабочим процессам уходили. Сейчас этот фокус не проходит. Например  не закрыли программу юзверы. Причем ушли они в 7-8 часов вечера, сервер (в 2 часа ночи) показывает что эти сеансы почему-то "не спят" (таймеры "сна" стоят в базе все по дефалту 1200/86400). Завершение работы сервера "аварией" судя по всему не считается, сеансы в "спящие" не переходят.

Как теперь всех гарантировано гонять всех с базы в нужный момент в 8.3? Скриптом выпиливать все сеансы из консоли кластера?

(0) Ну так установи таймер 600/3600, они уснут и отваляться

(1) а чего они при 1200 и промежутке времени с 20 до 2 ночи не засыпают? у них каких либо обработчиков ожидания нет чтобы "деятельность" симулировать

(2) У меня данных симптомов не наблюдается. Платформа какая?

клиенты работают в терминале?
на сервере ОС Windows Server x64?

(3) 8.3.9.2170

(4) >на сервере ОС Windows Server x64?

да

>клиенты работают в терминале?

и так и так

(5) одна из возможных причин зависания лицензий 1С в терминале на х64 сервере - это процесс "splwow64.exe", который запускается при печати, а завершается только через некоторое время.
если в этот момент закрыть 1С, то сессия зависает.
для решения проблемы нужно уменьшить тайм-аут завершения процесса splwow64.exe и добавить его в список процессов, завершаемых при завершении терминальной сессии
http://www.online-ufa.ru/content/articles/problem-1c-rdp/

что-то народ не понимает о чем (0) повествует

сейчас - можно открыть предприятие - появится сеанс пользователя

остановить сервер 1С -
запу3стить сервер 1с

продолжать работать в 1С не перезапуская сеанс предприятия

(0) - а таймеры сна - это где? - поэксперементирую

(2) - так - 1200 - это время засыпания
а 86400 - это через сутки после засыпания сеанс завершится

(0) "Скриптом выпиливать все сеансы из консоли кластера?"

Да

Или еще можно попробовать сделать больше интервал времени между "стоп сервис 1С" и "старт сервис 1С"

RAS + RAC спасет

и похоже БСП (или надо на чистой базе пробовать) - что-то там запрашивает (да даже динамический список автообновление)
сеанс в спящий переходит - потом фоновое - и опять не спящий

открытые клиенты не засыпают, так как в них есть обработчики ожидания на клиенте, которые сбивают таймер

а вообще очень просто - не выключил комп на ночь - оплатил электричество по ставке для ЮЛ в размере 10кВт/ч

сррразу же начнут выключать

(10) не поможет - "падение" сервиса не является аварией, процессы в спящие не переходят

(7) с ОФ же это не прокатывает?

(16) А зачем им переходить в спящие? Они просто отвалятся и всё.

(16) + что на мой взгляд является странным поведением для системы. сервер навернулся, а клиент на что-то надеется

(18) так вот и проблема - падение сервера не заставляет клиентскую сессию "засыпать".

(8) пофигуратор - администрирование - параметры ИБ
(15) они любят оставлять все в терминале выключив комп.

(20) Он заставляет её отвалиться. Но не сразу, а через время.

+(22) Но мы пользуемся обработкой, которая через консоль сеансы отключает. Хотя тоже не 100% надёжно. В редких случаях сеанс не удаётся срубить. :)

(22)

вчера вечером эксперементы ставил

4 сеанса, не спят.

стоп сервер

ждем допустим 5 минут

старт сервер

4 сеанса, не спят.

ЗЫ сколько ждать то надо?

(17) так поставь 30/30 - и посмотри что у тебя с сеансом в происходит

на БСП - см (13)
возможно у тебя в конфе нет подклюеных обработчиков

поставил таймеры 300/300

4 коннекта, не спят

стоп сервер

ждем 6 минут

старт сервер

4 коннекта, не спят

берешь и убиваешь такс руками с коннектом - сразу переходит в "спит" и через 5 минут выпиливается

(24) - так у тебя параметры - 1200 - это 20 минут - на засыпание
и 86400 - это 24 часа - на отваливание после засыпания

(24) А фиг его знает, какой сейчас нужен таймаут. У нас пару раз ночью сервер падал - к утру все сеансы разорваны. А для регламентов мы пользуем обработку.

в бсп есть все для программного завершения работы пользователей

(28) >- так у тебя параметры - 1200 - это 20 минут - на засыпание

в этом и проблема - если грохается сервер процессы не засыпают сколько не ставь. с одной стороны логично - сервер не действует - откуда он знает сколько клиент его ждет...

Такая же проблема... сейчас, в качестве костыля, просто тушу службу сервера на 1 час, что бы все отвалились, и потом запускаю бакап.
А вообще хочу допилить "робота", который будет заходить в предприятие и выгонять всех программно и потом уже запускать бакап. Правда хочу я это уже полгода и все времени нет, работает же "костыль" -)

(31) а что происходит на клиентах когда грохается сервер?
Они отваливаются? Процессы закрываются?

(0) а чем не устраивает программное ЗавершитьРаботу по флагу?

(33) из свойств процессов исчезает "рабочий процесс" сервера приложений, но они остаются - потом они или выпиливаются. или "перетираются" реальными процессами от тех же пользователей - по крайней мере утром юзеры заходят как обычно. А сервер ночью ругается что не может перевести базу в монопольный режим.

(34) не хочу зависеть от состояния "рантайма" самого приложения

(32) тушить на час... надо попробовать. но это слишком много... вроде на ИТС или у Гилева всплывала цифра в 20 минут - попробую столько задать для сна

Народ, это все-же программерский форум. А не сисадминский...

Коннектор = Новый COMобъект("V83.ComConnector");

Агент = Коннектор.ConnectAgent(Сервер);
Кластер = Агент.GetClusters().GetValue(0);

Агент.Authenticate(Кластер, "", "");

Процессы = Агент.GetWorkingProcesses(Кластер);
    
Для каждого РабочийПроцесс Из Процессы Цикл
    Если РабочийПроцесс.Running И РабочийПроцесс.Use Тогда
РабочийПроцесс.AddAuthentication(СтрокаБаз.Пользователь, СтрокаБаз.Пароль);

......Ну там много довольно

Суть в том что при помощи GetInfoBases() получаем список баз, находим свою.
Потом получаем соединения GetInfoBaseConnections(ИнформационнаяБаза);

и рвем их с помощью Disconnect(Соединение);

Только не рвем это соединение, через которое управляем...

Если Соединение.AppID = "COMConsole" Тогда
Продолжить;
КонецЕсли;

Не знаю как сейчас, а на 8.3.8 служба падала :-)

(37) Да, забыл. Перед тем как рвать соединения. я завершал сеансы. А уже потом соединения(в основном для зависших сеансов)

Сеансы = Агент.GetInfoBaseSessions(Кластер, ИнформационнаяБаза);
    Для каждого Сеанс Из Сеансы Цикл
        Если Сеанс.AppID = "SrvrConsole" Тогда
            Продолжить;
        КонецЕсли;
        Агент.TerminateSession(Кластер, Сеанс);