Нет активных пользователей в приложении кроме Конфигуратора, а сделать dt-выгрузку базы не дает, вроде кто-то есть в базе!? Приходится "выгонять" даже отключенных пользователей из терминала: https://i.ibb.co/LC9MwSc/image.jpg

"а сделать dt-выгрузку базы не дает" - так и пишет: "Не дам!" ?

(1) "дам, но не вам"

В Диспетчере задач посмотрите зависшие процессы 1с.

(1) Вроде (не точно) Ошибка исключительной блокировки информационной базы. Но после "Выход из системы" даже отключенных пользователей все нормально?
(3) Посмотрю (когда нужда заставить), программно их можно завершить, как?

(4) Если база серверная то, скорее всего соединение осталось висеть в каком нить rphost'е. Находите зависшее соединение, смотрите в каком рабочем процессе оно числится. У рабочего процесса находите PID, если там больше нет других соединений, то можете смело грохать rphost с данным PID. После этого конфигуратор даст вам выгрузить базу.

(0) База случайно не веб-сервере IIS
Тогда остановить службу IIS и проверить.

(5) Да, база SQL. Но SQL-сервер барахлить стал. Программно такую проверку можно сделать, и грохнуть если так? Желательно средствами 1С...
(6) Нет, не на веб-сервере IIS.

т.е. работаете в базе на скл, но не пользуетесь тулзой для администрирования 1С сервера ?!

Там же можно на каждой базе смотреть сеансы, в том числе и подвисшие покажет. И даже не только подвисшие, но и блокировки. А еще оно может показать, что там есть регламентные задания, выполняемые фоном под дефюзером на сервере.

(8) Консолью Администрирование серверов 1С Предприятия? Пользуюсь, обычно ей завершаю сеансы. Но после этого возникают такие проблемы (не точно).

(9) если лень разбираться и условия позволяют, перезапустите агент сервера, все зависшие соединения/сеансы должны грохнуться.

(9) бывают ситуации, когда сеанс завершен, а соединение осталось.
смотреть не только сеансы, но и соединения!

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

(10) уверенны ?

(10) не совсем так...

(13) (14) Один раз такое проканало. Был зависший сеанс, который нельзя было грохнуть через консоль, постоянно появлялся заново, не давал обновить конфу. Перезапустили агент сервера 1с и конфа нормально обновилась.

(15) Не, не одноразово, каждый вечер, думаю автоматом сделать... Когда то делал для файловых баз на 7.5.
Причем жестко завершать работу нельзя, проблемы с кассой: компьютер с кассой обычно всегда включен и подсоединен к базе, но кассир закрывает кассовую смену обычно удаленно с домашнего компьютера. Бывает срочная работа, которую нужно закончить "сегодня", и выгонять компьютер с кассой очень нежелательно. Перед архивированием просматриваю ЖР, закрыта ли кассовая смена. Если нет, то посылаю кассиру терминальное сообщение. Нет ответа - завершаю работу пользователей через консоль. Не получается - "выгоняю" (даже отключенных) пользователей из терминала.
В Альфа-Авто есть обработка Блокировки базы https://i.ibb.co/hmbSb6V/image.jpg, но не понял как она работает: есть начало и конец времени обработки. Кнопки 2-5-30... минут обновляют начало текущем временем, а конец - плюсует значение минут нажатой кнопки. Параметр вроде задает Интервал ожидания между предупреждениями пользователя о завершении работы. Если он не заполнен, то в обработке он 180 сек, но на деле меньше минуты.
По началу конец времени обработки казалось никак не влияет на процесс: Сразу после нажатия Установить начинаются выдаваться предупреждения, а затем само завершение. Самое странное, что после завершения работы Альфа-Авто вновь пытается запуститься!? Но не может, поскольку заблокирована. Пытаюсь сам ее запустить - нет, поскольку заблокирована. Насколько? Может это определяет конец времени обработки?
Запускаю нескольких пользователей, запускаю обработку блокировки, время ее начало отдвигаю на потом. Но она начинает действовать сразу после нажатия Установить!? Когда всех пользователей выгонит из Альфа-Авто, то начинает их вновь запускать!? Причем удачно, до заданного времени Начало обработки.
Где это делается: в самой Альфа-Авто или на системном уровне платформы?

Для клиент-серверных баз архив надо делать средствами СУБД, а не выгрузкой в dt. Выгрузка в dt - не является архивом.
Что касается вашей проблемы с зависшими сеансами, то вероятнее всего проблема с мусором во временных файлах сервера 1С, хранящих информацию о блокировках.
Мусор этот свален в папке кластера 1С srvinfo, название которой начинается с "snccntx".
Примерно так это выглядит путь к этой папке обычно C:\Program Files\1cv8\srvinfo\reg_1541\snccntx19d2777f-88d8-4633-a769-d00208de102e\.
Лечится проблема очисткой временных файлов кластера серверов 1С. Пример скрипта с сайта ИТС см. ниже.
Естественно пути и имена служб надо прописать свои.

set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="C:\Program Files\1cv8\srvinfo\reg_1541"
set PFL_PATH="C:\ProgramData\1C\1cv8"
set TEMP_PATH="C:\Windows\Temp"
echo stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout 5
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout 5
echo done stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
DEL /Q /F /S %CNTX_PATH%\snccntx*
DEL /Q /F %PFL_PATH%\*.pfl
DEL /Q /F /S %TEMP_PATH%\*.*
echo done clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo start %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
sc start %SERVICE_1C_NAME%
sc start %SERVICE_ RAS _NAME%
echo Service %SERVICE_1C_NAME% restarted at %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%


(17) В папке C:\Program Files\1cv8\srvinfo\reg_1541\ ничего кроме 1CV8Clst.lst нет. Сейчас, будут проблемы - посмотрю... спс!
А на счет (16) как?

(18) >> В папке  ничего кроме 1CV8Clst.lst нет.

Это нормально. Проблема не в самом наличии файла 1CV8Clst.lst. Проблема в его некорректном содержимом.
Удалить этот файл при работающих службах сервера 1С невозможно. Поэтому сначала надо остановить сервер, а потом файл удалить.
На последних версиях платформы такой проблемы не наблюдается. Но раньше периодически приходилось пользоваться тем скриптом, который я привёл в (17).

(18) >> А на счет (16) как?

Не знаю.
Я не очень понимаю для чего нужно повторно изобретать велосипед. Я в принципе противник велосипедостроения.
Во всех текущих версиях конфигураций с встроенной БСП везде есть обработка БлокировкаРаботыПользователей, которая запускается из панели Обслуживание раздела Администрирование. Там же есть консоль активных пользователей, из которой можно удалять сеансы вручную.

Или у вас какая-то древняя конфигурация на обычных формах или без БСП? В таком случае можете попробовать "сдёрнуть" решение из БСП или откуда-нибудь. Только зачем это нужно - не совсем понятно, если у вас есть доступ к консоли администрирования кластера 1С.

(20) Да, конфигурация на обычных формах или без БСП. Не понятно: когда обработка всех пользователей выгонит из Альфа-Авто, то начинает их вновь запускать!? Где это делается: в самой Альфа-Авто или на системном уровне платформы? Платформа 8.3.10.2466.

(21) >> Где это делается: в самой Альфа-Авто или на системном уровне платформы?

Понятия не имею. Надо смотреть. Как говорится, возможны варианты.
Ещё раз повторюсь. При наличии доступа к консоли администрирования кластера 1С написание подобных обработок - есть не более чем костылестроение. Пустая трата времени.

(22) Неужели на системном уровне платформы такое возможно? Альфа-Авто 4.1 создана для 8.2.

+ Оказывается используется команда ЗавершитьРаботуСистемы(<ЗапрашиватьВозможность>, <ПерезапуститьПриЗавершении>, <ДополнительныеПараметрыКоманднойСтроки>) с <ПерезапуститьПриЗавершении> = Истина.
В общем так, нужна проверка есть ли активные пользователи. Если есть, то запускать обработку мягкого завершения, с возможностью отказа пользователя от завершения. Компьютер с кассой выкидывать последним. Если все вышли из базы, то запускать dt-выгрузку базы.

сделайте снапшот и его выгружайте в дт

(24) я так и не понял почему, имея клиент-серверный вариант, выгрузка базы происходит путем создания dt файла, а не через инструменты sql? Где гарантия что потом этот dt развернется корректно? На мисте, не так давно был пост, как раз про это (не получалось развернуть ДТ файл из-за ошибки)

(26) пост 7 без комментариев

Как на зло ничего не мешает делать dt-выгрузку базы, пока...
Смотрю bat-файлы по dt-выгрузке, обычно делается в 3 этапа:
1. ENTERPRISE с блокировкой базы и ЗавершитьРаботуПользователей
2. CONFIG - непосредственная dt-выгрузка базы
3. ENTERPRISE для разблокировки базы и РазрешитьРаботуПользователей
Но при проблеме с кассой (16) нельзя жестко завершить работу пользователей. Можно ли определить есть ли активные пользователи в базе (за исключением конфигуратора)?

(28) как бэ..бэкап надо делать средствами скуля и не ипать мозг.
Ну или и дальше делать выгрузку в dt и потом, бегать сюда с вопросом, какого хрена из дт база не выходит..

(29) Как-то было SQL-сервер больше недели не работал. Пришлось использовать файловый вариант, хорошо была dt-выгрузка. Правда один день был потерян.

(30) В отпуске был что ле ?

как это  SQL-сервер больше недели не работал ?

(32) службу походу забыли запустить))

(30) А если сетка упадет на предприятии, будете риб разворачивать и на каждый комп по базе ставить?

(32) Сам до конца не понял объяснения сисадминов.
(28) + Не понял, как определяется что 1-й этап завершен, и можно делать dt-выгрузку?

+ Смотрю Ключи командной строки 1С v8 http://1cniku.ru/Articles/keyword.htm:
/Out<Имя файла>[-NoTruncate] - установка файла для вывода служебных сообщений. Если задан ключ NoTruncate (через пробел), файл не очищается.
Только через этот файл можно узнать завершен ли, и как 1-й этап?

Если в любом случае надо заходить в базу, то все завершения пользователей и проверки выполнять своей обработкой. При удачном ее выполнении, по ее завершению запускать конфигуратор для dt-выгрузки (при неудачном - нет). Эту обработку запускать регламентным заданием всю ночь каждый час при отсутствии файла dt-выгрузки?

(36) /Out<Имя файла>[-NoTruncate] - это и есть лог-файл?

(34) ты уверен, что у таких найдется кому риб развернуть, что он у них развернется и будет работать?

Все же, по вопросу (36): нет параметров командной строки, чтобы проверить: есть ли пользователи в базе?

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

(41) > консоль администрирования не удаляет сеансы...
Что и такое бывает? Не встречал. Иногда бывает в терминале пользователи отключены, а в 1С есть зависшие сеансы. Но консолью они прекрасно удалятся. А что консоль администрирования имеет свои параметры командной строки, не там ищу ответ на (40)?

(42) не тем вы занимаетесь, настройте уже нормальный регламент в sql по бекапам. Просто читая данный топик создается ощущение, что вы пытаетесь удалить апендикс через гланды, или ректально и спрашиваете, как это лучше организовать...На советы, мол сделайте общий наркоз, небольшой надрез в области живота и удалите, как положено, вы отмахиваетесь и говорите, мол я так когда то пробовал, шов потом долго у пациента заживал.

(42) эээээ.. ни разу не сталкивались с тем, что консоль не удаляет сеанс?

(43) Все это есть, но... (7) и (16). Ответ на вопрос темы дан в (17), но пока не представился случай его проверить.
Хотелось бы получить ответ на (40): можно ли проверить есть ли пользователи в базе не входя в базу в режиме 1С: Предприятие?

(35) пиндец контора
(43) ему бы бекапы sql не помогли никак, если у них тупо sql валялся неделю. Хотя, можно и свой sql поднять, раз админы ололо

(46) Ну так, вместо того, чтобы тратить столько времени на организацию выгрузки дт, которая не факт, что развернется (да и еще, если одна из таблиц будет более 4гб, вот веселуха с дт будет) лучше бы разобрались со сбоем sql и настроили его корректно.

(47) > тратить столько времени на организацию выгрузки дт
Поэтому сначала решил спросить, может кто делал нечто подобное...

на инфостарте есть обработка удаления зависших процессов

(49) Поточнее название бы, лучше ссылку..?

(17) Наконец-то вчера был зависший процесс кассира: висел в активных пользователях, и консоль его показывала. А в диспетчере служб удаленных рабочих столов все пользователи отключены (кроме меня). Но в папке C:\Program Files\1cv8\srvinfo\reg_1541\ ничего кроме 1CV8Clst.lst нет. Может временные файлы в другом месте? Делаю "Выход из системы": https://i.ibb.co/LC9MwSc/image.jpg - все пользователи исчезают, кроме зависшего кассира. Только консолью его выкинул.

(49) Вроде нашел: Поиск и отключение зависших сеансов на сервере 1С: Предприятия http://catalog.mista.ru/public/548893/. Автор пишет: К агенту сервера подключается через COMConnector. Но не пойму, входит ли она в базу?

(52) Для соединения через COMConnector в базе, к которой подключаются, создается пользователь с правами "Запуск внешнего соединения". Затем под этим пользователем происходит подключение, которое можно увидеть в режиме конфигуратора а также при помощи утилиты "Администрирование серверов 1С"

(53) + т.е. подключение есть и его можно увидеть стандартными способами

(53) > К агенту сервера подключается...
Не пойму: к базе, или к утилите "Администрирование серверов 1С"?

(17) ПОЧЕМУ "Выгрузка в dt - не является архивом" ?
Если из него можно восстановить/перенести как в файловую так и в сиквел.

(55) к базе
(56) "Не рекомендуется использовать механизм выгрузки / загрузки для создания / восстановления резервных копий информационной базы. Для создания / восстановления резервных копий используйте: для файлового варианта - средства программы "1С:Бухгалтерия 8" (ред. 3.0) в режиме "1С:Предприятие" (раздел: Администрирование - Обслуживание), для клиент-серверного варианта - средства используемой СУБД (подробнее см. здесь)."
https://its.1c.ru/db/answers1c/content/140/hdoc

(57) Работал на одной фирме, где было сделано так, что пользователь не мог зайти во второй раз. В результате пользователь не мог зайти в базу. Приходилось открывать консоль, и закрывать его зависший сеанс. А на другой было сделано что если в базе более полчаса ничего не делаешь, то тебя выкидывает из базы. Никогда не интересовался как это сделано, вряд ли все это в базе делается?

(58) ёёё.. открой уже параметры базы в пофигураторе

+59 Администрирование-параметры инф. базы..

(59) Зачем?

(58) откроешь для себя параметры "А на другой было сделано что если в базе более полчаса ничего не делаешь,"

(62) Это было сделано этими параметрами? Сейчас у меня в базе стандартные значения:
время ожидания блокировки - 20 с.
время засыпания - 300 с.
время завершения спящего сеанса - 10 с.
Нет, изменяя эти параметры наверное можно снизить вероятность зависания сеансов, но исключить...

(57) много раз читал что не dt нужно из серверной, но почему ни где не объясняется.

(64) так открой этот самый дт и посмотри, авось поймешь, почему не рекомендуется бакапить в него.

(64) ты просто не восстанавливал людям базу из битого dt файла. Когда файл есть, а загрузить из него ничего нельзя.
Такой файл - битую выгрузку, получить можно на раз два при ошибках в иб.

(65) dt-выгрузка предназначена не для архива (или не только), а для создания файловой базы из клиент-серверной (30), или наоборот.

(67) А че мне об этом заявлять-то?! мыша тыкается у тебя куда попало?

(65) Ух ты, а сам открывал?
для клиент-серверного варианта - средствами используемой СУБД).

(69) ну ты полоску многоцветную отрастить смог - почет и уважуха - но в дт файл посмотреть так и не додумался... Ну что тут еще сказать, кроме как на ветку замок повесить и отправить ее к праотцам.