Всем доброе время суток !

Фирма 1С подложила большую свинью пользователям.

При обновлении типовой Бухгалтерии с релиза 3.0.88.22 на 3.0.89.34 перед принятием изменений о реструктуризации происходит вылет со следующей ошибкой

Ошибка при выполнении файловой операции  'v8srvr://<адрес сервера 1С>/<имя базы>/Params/DBNames'
по причине:
Ошибка при выполнении файловой операции  '<адрес сервера 1С>/<имя базы>/params'


После этого в база остается без пользователей (происходит разрушение таблицы в которой хранится информация о пользователях).

При этом на официальном сайте в описании обновлений об этой особенности ни слова. Релиз существует в списке обновлений и не отозван.

Ошибка повторилась при обновлении трех разных баз 1С.


Будьте внимательны и не забывайте делать резервнвые копии перед обновлением.

(0) купите лицензию!

(1) Все лицензионное.

Платформа какая?

8-ый кактус надо есть не морщась!

(0) обновлял файловую с релиза 3.0.88.22 на 3.0.89.47, полет нормальный

+ платформа 8.3.18.1334

С релизом релизе 3.0.89.54 явно что то не то.

Сейчас периодически выскакивает сообщение "Сеанс завершен администратором".

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

(3) 1С:Предприятие 8.3 (8.3.17.1851)

ясно что дело в платформе а не конфиге.
странно что тс вообще 1с ник

(0)Небось все на одном компе пробуешь делать? Как минимум, надо попробовать с другого.

(9) >ясно что дело в платформе а не конфиге.

Да что ты говоришь.

Почему то на релизе 1С:Предприятие 8.3 (8.3.17.1851) с конфой 3.0.85.25 все работало стабильно.

Стоило поставить обновления релиза и понеслось - то таблица пользователей вынесена при обновлении то сеанс завершен администратором. Хотя администратор ничего не завершал.

(10) С разных пробовал. Вынос таблицы пользователей при обновлении происходил с разных компов.

Тии что?

Проверил на демо-базе на тех же релизах и платформе.
Кроме сообщения: "ОбщаяКартинка.Информация: Имя не уникально!" - никаких проблем нет.

(7) Может дело вообще не 1С? Проблема явно на сервере, может там винда каких обновлений наставила, или антивирус обновился, или тупо место кончилось в темпах...

(11) Дмитрий, конечно, администратор ничего не завершал, а вам нужно обратиться к специалисту.

(16) Во, Ежов, вопрос тебе:
Обновили сервер приложений до 8.3.1283, регламентные задания на сервере перестали работать)
История такая, запускаешь рег. задание из под доменного пользователя, с админскими правами, все работает.
А из консоли не пашет.
И комконнектор перерегистрировали, ЖР сервака пустой.
В базе из которой надо вытащить данные, отлично работает.
В серверных логах пусто.
Как отладить проблему?

(0) бггг, проснулся

уже перемололи 100 раз эту тему + на партнерке тема есть

Пользователь ИБ не идентифицирован

(16) Да администратор ничего не завершал. Как бы странно это не выглядело. Кто является администраторами этого сервера я знаю.

Однако при сохранении конфигурации выскакивает сообщение "Сеанс завершен администратором".

При этом в свойствах кластера отключено "принудительно завершать проблемные сеансы". Отключен перезапуск процессов. Отключен интервал превышения памяти.

А сеансы тем не менее завершаются.

(19)

"Уважаемые пользователи! При использовании платформы версии 8.3.18.1208 могут наблюдаться серьезные замедления работы программы. В очередном выпуске платформы 8.3.18 эта проблема будет устранена, а пока используйте версию 8.3.16.1814 или 8.3.17.1851. Приносим извинения за доставленные неудобства".

Так у меня релиз 8.3.17.1851.

И вплоть до релиза 3.0.85.25 все работало отлично.

Проблемы полезли при обновлении под этим релизом на 3.0.88.22.

(16) >конечно, администратор ничего не завершал

А у тебя конечно же есть доказательства что сообщение "Сеанс завершен администратором" это действие злобного сисадмина который сидит и жмет на кнопку "завершить сеанс пользователя" и злобно хохочет при этом.

А не глюки конфигурации.

(15) >Проблема явно на сервере

В понедельник с начальником отдела будем смотреть. Что происходит на сервере в момент "Сеанс завершен администратором" .

Я такого бреда давно не видел чтобы сеансы завершались без действия пользователя и когда отключены все варианты сброса / перезапуска процессов на серверею

8.3.17.1851, 3.0.89.34 - всё ок, проблем при обновлении не было.

Про работу пользователей в 3.0.89.34 не знаю, потому что обновлялись дальше по линейке релизов.

(24) Отключение перезапуска процессов ни разу не защищает от их аварийного падения. Странно винить конфигурацию, если в (22) проговорился что проблемы начались раньше.
Сервер x64?

(24)[Я такого бреда давно не видел чтобы сеансы завершались без действия пользователя]
ошибка типовая, у Гилева описана, безусловно не является бредом и ни как не связана с настройками кластера.
А ещё у неё(ошибки) есть код

а модет проблема из этой серии последние 2-недели у всех все падает пока не удальшь

https://www.bleepingcomputer.com/news/microsoft/windows-10-crashes-when-printing-due-to-microsoft-march-updates/
wusa /uninstall /kb:5000802
wusa /uninstall /kb:5000808

(28) >ошибка типовая

Речь про "Сеанс завершен администратором" когда никакой администратор ничего не завершал ? А можно ссылку на эту ошибку у Гилева ?

(27) >проблемы начались раньше.

Проблемы раньше не было. Я с этим сервером работаю третий год, ни разу бреда подобного "Сеанс завершен администратором" когда никакой администратор ничего не завершал не было.

На релизе 8.3.17.1851 все работало стабильно уже месяца четыре. Но как только захотел обновиться с 3.0.85.25 на 3.0.88.22 на трех базах словил разрушение таблицы пользователей при обновлении. И полезли ошибки "Сеанс завершен администратором" когда никакой администратор ничего не завершал.

(30) http://www.gilev.ru/err80004005/

(31) тебе уже раз 20 написали, что к живому администратору эта ошибка отношения не имеет

это не завершение администратором, а упавшие процессы

(23) > А у тебя конечно же есть доказательства
На полиграф их всех!

(32) Спасибо

(27) >Отключение перезапуска процессов ни разу не защищает от их аварийного падения

Помогло следующее

Перезагрузка сервера (не перезапуск служб а именно перезагрузка).

После этого ошибка "Сеанс завершен администратором" прекратилась.

Но вынос таблицы пользователей все равно один раз еще словил перед применением изменений. Пришлось восстановить базу из скульного бжкапа и повторить этот шаг


Короче сейчас процедура обновления вынуждено превращается в цикл "сделали шаг - сделали скульный бэкап" при каждом шаге обновления.

(34) Вопрос почему эти процессы падали.

(38) скорее всего глюки платформы как обычно

По результатам произошедшего возник один вопрос.

Можно ли каким то образом на время выполнения обновления блокировать регламентные задания сразу на ВСЕХ базах ?

Предположим баз на сервере 50-100 и зайти в каждую в свойства и проставить галочку блокировки проблемно.

(40) что-то мешает манипулировать флагом программно ?

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

(40) пора уже давно для обновления скрипт написать.
ну или юзать обновлятор

(40) кстати да. регламентные задания это отдельная тема для обсуждения. В нашей нетленке фоновых заданий не было и мне непонятно зачем они вообще в 8ке. Коллеги долго пытались мне объяснить что на 7ке и на меньшее количество пользователей нужны фоновые задания, но я так и не поняла.

(44) Тонко )

(41) >что-то мешает манипулировать флагом программно

Я собственно про это направление и спрашивал.
Поскольку нигде в параметрах сервера 1С нет галочки "запретить выполнение регламентных заданий со всех базах".

(43) >пора уже давно для обновления скрипт написать

Вот и обновляй скриптом свое ERP.

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

(42) Странно что фирма 1С до сих пор этого не сделала. Хотя бы для лицензий уровня Корм.

Заниматься всякой ерундой и придумывать чат-ботов в 1С ей времени хватает а на полезные вещи нет.

(47)  а как обновление руками спасет?

а как ты вообще 50 баз руками обновляешь?
У тебя на что-то другое время остается?

(48) Нууу... я бы так не сказал, что 1С ерундой занимаются... погуглите "требование назначения функциональности", "BackgroundJob"...
Например, https://www.youtube.com/watch?v=xWTuM3u7SFU&t=5s

При помощи ras и rac ставить/убирать различные "галки" в свойствах ИБ достаточно легко и просто. При наличии некоторых предварительных знаний, конечно.

(50) У меня 8 баз БП и 1 ЗУП на сопровождении.
Которые обновляются раз в квартал.

Когда 50 баз то все изменения выносятся в расширения, конфа ставится на поддержку и на обновление сажают девочек которых учат накатывать релизы один за одним.

(51) >я бы так не сказал, что 1С ерундой занимаются

Я к тому что 1С ГОДАМИ не вводит в свои релизы реально полезные вещи. А тратит время и силы разработчиков на всякую ерунду. Вместо того чтобы доделать и дать в руки программистов инструмент который позволит через метаданные смотреть у какого реквизита и какой формы включен признак изменений 1С занимается доработкой чат-ботов.

(51) >погуглите "требование назначения функциональности"

Все это замечательно, но какому проценту организаций это надо ?

У многих организаций есть несколько серверов 1С, или отдельно сервер 1С и отдельно сервер под БД ?

"Сеанс завершен администратором" - это падает регламентное задание.

Может что с полнотекстовым поиском? Попробуй очистить.

Отключай регламентные задания, пока не найдешь виновника.

А может платформа ломаная, тоже вылеты такого типа могут быть.
Поставь платформу, выпущенную до 19.11.2020 и проверь

Проверь на другом сервере, где 100% лицензия.

Поставь все с нуля на чистую машину, активируй и проверь.

Ты хочешь сказать, что с 08.02.2021 только у тебя первого проблема всплыла?
Ищи проблемы в системе своей, релиз тут ни при чем.

(56) Ошибка "Сеанс завершен администратором" ушла после перезагрузки сервера.

До перезагрузки ничего не помогало от нее избавиться.

После перезагрузки сервера обновление баз пошло как по маслу.

>Отключай регламентные задания, пока не найдешь виновника.


Я отключал регламентные задания только в той базе которая обновлялась. До перезагрузки сервера это не помогало. В следующий раз если подобная ситуация возникнет попробую проставить блокировки регламентных заданий во всех базах (а не только в той которая обновляется).

(56) Просто в этот раз впервые за почти три года обновления баз на этом сервере словил и "Сеанс завершен администратором" и вынос таблицы пользователей перед применением изменений.

Ну ничего страшного, теперь делаю скульный бэкап базы которая обновляется несколько раз.

(41) >что-то мешает манипулировать флагом программно

Для того чтобы "манипулировать флагом программно" надо сначала узнать что сервер 1С позволяет "манипулировать флагом программно".

Вот и все.

То есть для того чтобы найти клад надо знать хотя ы приблизительно куда копать.

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

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

(56) Для меня во всей этой истории осталось загадкой только то почему помогла только полная перезагрузка сервера 1С.
Перезапуск процессов сервера 1С не помогал избавиться от ошибок "Сеанс завершен администратором" и выноса таблицы пользователей перед применением изменений.

(62) >идет выполнение фоновых заданий

Я обратил внимание что в базе при обновлении даже при установленной галочке "блокировка регламентных заданий" проскакивало "системное фоновое задание".

Ты про это ?

Проблема с обновлениями такого рода, как тут довольно долго обсуждается, оно было раньше в каком-то из релизов. Чтоб решить эту проблему тогда была возможность на версии ПРОФ на сервере включать использование "одна база на процесс". Тогда все возможные фоновые задания друг друга в разных базах не затрагивают и обновление проходило, причем, с гораздо более высокой скоростью, т.к. блокировки из разных баз становились не влияющими на соседние базы.

Доходило даже до того, что на небольших базах можно было выполнить намного быстрей обновление в файловом режиме и уже обновленную загружать в сервер.

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

к 65 + возможно, что на самых последних релизах БСП уже сделали автоматическую настройку, которая умеет запускать процедуры обновления не в фоновом, а непосредственно, даже при запрете запуска регламентных заданий

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

Ну так это же штатный механизм.

1. Обновить конфигурацию.
2. Разблокировать регламентные задания.
3. Администрирование - Обслуживание - Обновление программы - Результаты обновления программы.
Убедиться что там все выполнено.

Без выполнения пункта 2 пункт 3 не выполнится.

(66) >сделали автоматическую настройку, которая умеет запускать процедуры обновления не в фоновом, а непосредственно, даже при запрете запуска регламентных заданий

Сомневаюсь.

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