Имеем 2 независимых физических сервера.
На обоих до недавнего времени был установлен сервер 1С версии 8.3.13.
Угораздило вляпаться в 8.3.16.1063.
Обновили настройки серверов в соответствии с лицензией уровня ПРОФ, соблюдая все новые ограничения.
Всё взлетело. Есть мелкие косяки в работе обычных форм, но это мелочи.
Основная проблема - оба сервера начали иногда терять аппаратные ключи по ночам. Ключ светится, в диспетчере устройств есть, перевтыкание не помогает - сервер 1С его не видит.
Закономерность выявить не удается. Приходим утром - "Не обнаружена лицензия на запуск сервера". Техники ребутят сервер - всё снова работает несколько дней.
На сервере 1С:Предприятия не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия!
по причине:
локальный ключ недоступен: Status=0, ENSR8 Локальный, не установлен
Файл программной лицензии не найден
локальный ключ недоступен: Status=0, EN8SA Локальный, не установлен
Поиск лицензии в сервисе лицензирования:
Файл программной лицензии не найден
На 8.3.13 проблем не было. Два аппаратных ключа на разных серверах не могли начать глючить одновременно.
В перечне известных ошибок платформы данный баг найти не удалось.
Кто-то еще сталкивался?
Как решается?
Пока на ум приходит только ежедневный рестарт сервера 1С до начала рабочего дня.
Установить 8.3.15.1778 ! И не торопиться переходить на 8.16 , так как помимо проблем с ключами , есть проблемы и с принтерами и с запросами оборотных регистров ( выдает разные результаты Пример: Запрос на платформах 8.3.13 ,8.3.14,8.3.15 результат = 10, на 8.3.16 результат = 0 )
2.
PhoenixAOD
6216.12.19 04:36 Сейчас в теме+0.33 $m
(1)у меня 8.3.15.1656 стоит, таких бед не наблюдается. А вообще манагер Хаспа чего-то говорит по этому поводу? Сами ключи не отваливаются как девайсы в диспетчере?
(4) была мысль. Только вот проблема не локализована.
В центре лицензирования тоже не экстрасенсы работают. Уверен, что в ответ пришлют общие рекомендации типа "обновите драйвер ключа, используйте другой юсб-порт, замените ключ".
Проблема возникла одновременно на 2ух серверах при обновлении до 8.3.16.1063. Я процентов на 90% уверен, что это глюк релиза, тк таких совпадений не бывает. Меня смущает, что я не смог найти никакой информациях на профильных ресурсах относительно этой ошибки данного релиза и подтвердить свою догадку.
(5) Я всмысле про то, что если это ошибка платформы, то им возможно уже обращались с подобными вопросами. А вообще в новых платформах ведется лог лицензий где записывается конфигурация компьютера на момент установки лицензий и на момент слета. Я так однажды определил, что сисадмин периодически менял объем жесткого диска (на вирт. сервере), хотя до этого ни в какую не признавался и говорил что не в курсе почему лицензии слетают :)
По поводу железа... В голову приходит только возможное наличие на сервере RAM-дисков динамического объема...
Спасибо за наводку на лог лицензий. Изучу информацию.
Установить 8.3.15.1778 ! И не торопиться переходить на 8.16 , так как помимо проблем с ключами , есть проблемы и с принтерами и с запросами оборотных регистров ( выдает разные результаты Пример: Запрос на платформах 8.3.13 ,8.3.14,8.3.15 результат = 10, на 8.3.16 результат = 0 )
(7) Решение о выборе платформы принимал не я. Я бы дальше 8.3.14 прыгать не стал.
Я конечно могу поднять вопрос о необходимость отката до ближайшего стабильного релиза, озадачить технический отдел, но хотелось бы быть уверенным, что это ошибка платформы и её нет возможности исправить без отката.
Но я нигде не могу найти этому официального или хотя бы косвенного подтверждения, хотя релизу уже 4 недели.
Но я нигде не могу найти этому официального или хотя бы косвенного подтверждения, хотя релизу уже 4 недели.
4 недели -это не срок...
как вам такие финты
"Повышение стабильности при работе с принтерами
Повышена стабильность при работе с «проблемными» принтерами. Ранее недоступность принтера могла приводить к недоступности всей платформы или проблемам с закрытием терминальной сессии. Проблемы с драйверами — к падению. В новой версии платформы работа с принтерами вынесена в отдельный процесс и указанные выше проблемы больше не будут беспокоить пользователей."
и тут же не является ошибкой
"Описание:
При использовании удаленного доступа к рабочему столу печать на некоторые принтеры, например, Kyocera, может выполняться некорректно.
Способ обхода:
Не использовать терминальный сервер, использовать другие принтеры."
это как?
А на все документального подтверждения и не найдете! потому как баг лист составляется только после регистрации ошибки в 1с и ее подтверждения!
"Описание:
При использовании удаленного доступа к рабочему столу печать на некоторые принтеры, например, Kyocera,
Да-да. И способ решения - "купите другой принтер или не используйте терминалы". Читал, тоже вызвало недоумение.
Я не спорю, что в 8.3.16 куча косяков. Другое дело, что с ними в нашем конкретном случае пока можно жить и ждать более стабильной версии 8.3.16.
А вот потеря лицензий - с этим мириться мы не можем.
Я пытаюсь найти хоть кого-то у кого есть именно этот глюк на этом релизе. Пока глухо =( .
(11) а вот это "разные результаты Пример: Запрос на платформах 8.3.13 ,8.3.14,8.3.15 результат = 10, на 8.3.16 результат = 0" c 08.11.19 и повторно с 21.11.19 находится на проверке! ( ждите ответа ) :) И как ошибку не зарегали , и не отклонили... ждемс :(
(12) У себя пока не сталкивался с этим. Думается, что если бы эта ошибка проявлялось повсеместно во всех конфигурациях, то это был бы повод для отзыва релиза с ИТС.
(13) Типовая УПП с 1.3.96.1 по релиз 1.3.128.2 ( других под рукой не было ) и на типовой демо тоже , причем кривой результат выдает только в клиент-серверном исполнении :) в файловом все ок :).
а ответ поддержки " ...бла бла бла... УПП не предназначена для использования на 16 платформе используйте платформу 12 или 13 " вот такие они молодцы :)
(22) она самая только по факту только на 8.3.17.1032 ( тестовой ) , все считает правильно , и даже на 8.3.16.1148 (тестовой) вышедшей 14.01.2020 это косяк воспроизводится
(7) на платформах 8.3.12, 8.3.13, 8.3.14 наблюдал проблемы с отборами в СКД (видимо по другому отрабатывает запрос с SQL). Проблема на типовом отчете "Ведомость по учету затрат" для нас это очень большая проблмеа, на 8.3.15 такой проблемы нет, но есть проблемы с вылетами по дампу при проведении документов, отправкой писем, масштабирование при печати. Остаётся пробовать 16й релиз, 1С не оставила альтернатив
(2) В диспетчере ключ виден.
Служба сервера 1С его не находит, пока не ребутнешь.
Ребут службы сервера 1С помогает, отсюда я делаю вывод, что проблема вероятнее всего не железная, а софтовая и она где-то на стороне сервера 1С. Да и какова вероятность, что железная проблема появилась одновременно на двух разных физических серверах, находящихся в разных зданиях.
При очередном глюке постараюсь заглянуть в Хасп менаджер. Глубоко не копали, с утра нужно было быстро запускать офисы в работу. Потому и прошу коллег поделиться опытом =).
(16) Sentinel Run-time Installer какой версии используется? Сейчас последняя - 7.102.
Может, 8.3.16 ведет себя так с более старыми версиями.
Сам aksusbd, при этом, не подвисает? Когда-то ранние версии Sentinel Run-time Installer этим грешили, самопроизвольным подвисанием, даже приходилось в cron-е скрипт держать, который проверял раз в несколько минут статус и, при необходимости, делал рестарт aksusbd.
(17) aksusbd-7.100.1. Весь софт х64
никаких подвисаний не наблюдаю... используем эту версию пару месяцев.
Костыль после сегодняшнего случая тоже подставили... раз в сутки рестартовать весь этот зоопарк.
В логах вот это:
Dec 18 10:49:19 db kernel: [1888693.674150] INFO: task aksusbd_x86_64:542 blocked for more than 120 seconds.
Dec 18 10:49:19 db kernel: [1888693.674176] Tainted: G O 4.9.0-11-amd64 #1 Debian 4.9.189-3+deb9u2
Dec 18 10:49:19 db kernel: [1888693.674197] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 18 10:49:19 db kernel: [1888693.674213] aksusbd_x86_64 D 0 542 1 0x00000000
Dec 18 10:49:19 db kernel: [1888693.674215] 0000000000000086 ffff9e1c791e2800 0000000000000000 ffff9e1c7c8d3040
Dec 18 10:49:19 db kernel: [1888693.674217] ffff9e1cc51d8980 ffff9e1c7dd0a080 ffffb160c6fbfc38 ffffffff84619609
Dec 18 10:49:19 db kernel: [1888693.674218] ffff9e1878fe1840 0000000000000296 ffff9e1cc51d8980 ffffffffc01800b0
Dec 18 10:49:19 db kernel: [1888693.674219] Call Trace:
Dec 18 10:49:19 db kernel: [1888693.674224] [<ffffffff84619609>] ? __schedule+0x239/0x6f0
Dec 18 10:49:19 db kernel: [1888693.674225] [<ffffffff84619af2>] ? schedule+0x32/0x80
Dec 18 10:49:19 db kernel: [1888693.674232] [<ffffffffc0163546>] ? usb_kill_urb+0x86/0xc0 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674233] [<ffffffff840beb30>] ? prepare_to_wait_event+0xf0/0xf0
Dec 18 10:49:19 db kernel: [1888693.674238] [<ffffffffc0163ba2>] ? usb_start_wait_urb+0xe2/0x170 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674241] [<ffffffffc0163d0d>] ? usb_control_msg+0xdd/0x140 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674245] [<ffffffffc016e397>] ? proc_control+0x2d7/0x3f0 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674249] [<ffffffffc0170427>] ? usbdev_do_ioctl+0x717/0x1250 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674250] [<ffffffff84264f3e>] ? do_lock_file_wait+0x4e/0xd0
Dec 18 10:49:19 db kernel: [1888693.674254] [<ffffffffc0170f7a>] ? usbdev_ioctl+0xa/0x10 [usbcore]
Dec 18 10:49:19 db kernel: [1888693.674255] [<ffffffff84221c82>] ? do_vfs_ioctl+0xa2/0x620
Dec 18 10:49:19 db kernel: [1888693.674256] [<ffffffff84222274>] ? SyS_ioctl+0x74/0x80
Dec 18 10:49:19 db kernel: [1888693.674258] [<ffffffff84003b7d>] ? do_syscall_64+0x8d/0x100
Показать
Используем два сервера (одинаковое железо, одинаковый софт).
На первом этот глюк поймали сегодня, впервые. Сервер не сказать что сильно нагружен. 5 баз, около 50 сеансов.
На втором такого не наблюдал ни разу... правда на нем и нагрузки никакой
месяц назад обновились с 8.3.13.1513 на 8.3.14.1976.
18.12.19 вышла новая конфа БП 3.0.75.37, требующая минимум 8.3.15.1747
Хотели обновиться на 8.3.16.1063, но почитав отзывы, решили остановиться на 8.3.15.1778.
На долго ли ее хватит не знаем.
Установили платформу 8.3.16.1063 (клиент 32х, сервер 64х). При входе 17-го пользователя получил сообщение "Операция не может быьть выполнена с текущим составом лицензий...." Надо настроить параметры кластера сервера 1С как описано тут https://infostart.ru/public/1119524/ В ЗУП 3.1.11.113 и 3.1.12.110 на форме документа "Исполнительный лист" по щелчку на гиперссылке(разворачиваемой группе реквизитов) аварийно вылетает клиент. Ошибка на уровне движка клиента. Решили изменением формы. Группа элементов из "свертываемая" на "обычная".