Мы сталкиваемся с распространенной и крайне неприятной проблемой, которая проявляется на серверах 1С:Предприятия, работающих под управлением платформы версии 8.3.16.1063 и иногда на более поздних релизах, таких как 8.3.25.1394. Суть проблемы заключается в том, что сервер периодически, чаще всего в ночное время или после длительного простоя, перестает видеть аппаратный ключ защиты HASP. При этом физически ключ продолжает светиться, в диспетчере устройств он определяется корректно, и даже перевтыкание его в USB-порт не помогает. Служба сервера 1С:Предприятия перестает обнаруживать лицензию, выдавая сообщения вида: «Не обнаружена лицензия на запуск сервера», «Не обнаружен ключ защиты программы или полученная программная лицензия! по причине: локальный ключ недоступен: Status=0, ENSR8 Локальный, не установлен». Единственным временным решением становится перезагрузка всего сервера или, что чаще, перезапуск службы сервера 1С:Предприятия. Эта ситуация вызывает серьезные простои в работе и требует постоянного внимания системных администраторов. Давайте разберем эту проблему подробнее, рассмотрим возможные причины ее возникновения и предложим комплексные решения.
Мы выясняем, что одной из наиболее вероятных причин проблемы является нестабильность самой платформы 1С:Предприятия версии 8.3.16.1063 и смежных релизов. Многие пользователи сообщают о возникновении данной ошибки именно после обновления до этой версии. В то же время, на предыдущих стабильных версиях, таких как 8.3.13, 8.3.14 или 8.3.15, подобных проблем не наблюдалось. Это указывает на то, что в данном релизе могли быть внесены изменения, которые некорректно взаимодействуют с механизмом работы аппаратных ключей защиты. 1С не всегда оперативно регистрирует и публикует информацию о всех выявленных ошибках, поэтому отсутствие официального подтверждения в списке известных проблем не означает, что бага не существует. Помимо проблем с ключами, эта версия платформы также может демонстрировать нестабильность в работе с принтерами, некорректные результаты запросов оборотных регистров и другие «косяки», что косвенно подтверждает ее общую недоработанность.
Рассматривая проблему потери ключа, мы обязательно обращаем внимание на состояние драйверов, обеспечивающих его работу. Аппаратные ключи 1С:Предприятия используют технологию HASP (ныне Sentinel), для корректного функционирования которой необходим установленный пакет драйверов Sentinel Run-time Installer (также известный как HASP License Manager). Мы проверяем версию установленного драйвера: устаревшие версии могут быть несовместимы с новыми версиями платформы или операционных систем. На момент возникновения проблемы (8.3.16) актуальной версией мог быть 7.102, в то время как у некоторых пользователей стояла 7.100.1. Также мы должны учитывать, что работа USB-ключа зависит от стабильности USB-контроллеров самого сервера. Возможны следующие проблемы:
aksusbd: На серверах под управлением Linux мы можем наблюдать сообщения в ядре о блокировке процесса aksusbd_x86_64. Это указывает на то, что менеджер лицензий HASP зависает, не отвечая на запросы платформы 1С. В таких случаях перезапуск только этой службы может помочь, а также грамотное обслуживание баз данных 1C на Postgresql под Astra Linux.Мы рассматриваем возможность того, что проблемы с лицензированием могут быть вызваны конфликтами с установленным на сервере антивирусным программным обеспечением или другими системами безопасности (например, файрволами). Антивирусы могут блокировать доступ к файлам лицензий, процессам 1С (rphost, rmngr, ragent) или службе HASP License Manager, воспринимая их активность как подозрительную. Мы рекомендуем:
ragent.exe, rmngr.exe, rphost.exe, а также папку установки HASP License Manager и его исполняемые файлы (например, nhsrvice.exe для Windows или aksusbd для Linux).В ходе анализа проблемы мы обнаруживаем, что потеря ключа может быть косвенно связана с перегрузкой процессов rphost сервера 1С:Предприятия. На серверах со значительным количеством баз данных и активных пользователей, особенно если используется 32-битный rphost (даже на 64-битной ОС), возможно достижение лимита памяти, доступного для одного процесса (обычно около 3-4 ГБ). Когда процесс rphost достигает этого лимита, он может начать работать нестабильно, зависать или некорректно взаимодействовать с другими службами, включая менеджер лицензий HASP. Это может проявляться как «потеря» лицензии, поскольку rphost становится неспособен запросить или подтвердить ее наличие. Мы можем наблюдать, что проблема обостряется при добавлении новых баз или увеличении нагрузки, особенно если в ночное время активно выполняются регламентные задания.
Если сервер 1С:Предприятия установлен на виртуальной машине, а аппаратный ключ пробрасывается через USB-порт хост-системы (например, VMware ESXi), мы сталкиваемся с дополнительными факторами риска. Проброс USB-устройств в виртуальные машины не всегда является идеально стабильным решением и часто не документируется как официально поддерживаемый сценарий для критически важных приложений. Мы учитываем, что стабильность работы в этом случае зависит не только от платформы 1С и драйверов HASP, но и от версии и настроек программного обеспечения виртуализации. Возможные проблемы:
VMware Tools (или аналогичных инструментов для другой виртуализации) и обновлена сама платформа виртуализации (например, VMware ESXi).В некоторых случаях, если менеджер лицензий HASP (Sentinel License Manager) установлен на отдельном узле сети, проблемы с потерей лицензии могут быть вызваны сетевыми задержками или нестабильностью сетевого соединения между сервером 1С и сервером лицензий. Мы проверяем следующее:
Мы приходим к выводу, что наиболее радикальным, но часто самым эффективным решением проблемы потери ключа на платформе 8.3.16.1063 является откат на более стабильный релиз. Многие пользователи, столкнувшиеся с данной проблемой, успешно решили ее, вернувшись на платформу 8.3.15.x. Конкретно, рекомендуется версия 8.3.15.1778 или 8.3.15.1656, поскольку на этих релизах подобные проблемы не наблюдались. Если текущие конфигурации не требуют строго версии 8.3.16, мы рассматриваем этот вариант как приоритетный. Для выполнения отката:
Этот подход позволяет избежать неизвестных проблем, связанных с конкретным нестабильным релизом, и обеспечивает надежное функционирование системы.
Если откат на предыдущую версию платформы по каким-либо причинам невозможен, мы можем применить обходной путь в виде автоматического ежедневного перезапуска службы сервера 1С:Предприятия или службы HASP License Manager (aksusbd). Этот метод не решает корневую причину, но позволяет избежать ручных перезагрузок и обеспечить доступность системы к началу рабочего дня. Мы реализуем это с помощью скриптов, запускаемых по расписанию:
Мы создаем пакетный файл (например, restart_1c_service.bat) со следующими командами:
net stop "1C:Enterprise 8.3 Server Agent (x86-64)"
timeout /t 10 /nobreak
net start "1C:Enterprise 8.3 Server Agent (x86-64)"
Затем мы настраиваем планировщик заданий Windows на запуск этого файла ежедневно в нерабочее время (например, в 4:00 утра).
Мы используем помощник установки и обновления сервера 1С или стандартные команды для перезапуска службы сервера 1С или службы aksusbd (менеджера HASP):
sudo systemctl restart 1c-enterprise@.service
# или для HASP-менеджера:
sudo systemctl restart aksusbd
Мы добавляем соответствующую команду в планировщик cron для ежедневного выполнения, при этом можно использовать рестарт сервера 1С с очисткой сеансовых данных на Linux.
При этом мы внимательно выбираем время для перезапуска, чтобы оно не пересекалось с работой пользователей или важными регламентными операциями.
Мы активно работаем над устранением проблем на уровне операционной системы и драйверов. Наши шаги следующие:
Sentinel Run-time Installer: Мы загружаем и устанавливаем последнюю версию драйверов HASP с официального сайта Gemalto (SafeNet/Thales) или с сайта 1С. На момент обсуждения актуальной могла быть версия 7.102 или новее. Мы убеждаемся, что устанавливаем версию, соответствующую архитектуре сервера (x64 для 64-битного сервера).
Мы выполняем следующие действия в Windows:
USB Root Hub) и, если есть, Generic USB Hub:
Если мы наблюдаем потерю ключа, связанную с перегрузкой памяти процессов rphost, особенно при наличии множества баз данных и регламентных заданий, мы применяем решение, описанное в одном из сообщений форума. Этот метод особенно актуален для систем с лицензией уровня КОРП (PROF-лицензия имеет ограничения на количество процессов rphost для одной ИБ). Суть решения заключается в распределении информационных баз по отдельным рабочим процессам:
rphost. По умолчанию, один процесс rphost может обслуживать несколько информационных баз. Однако при таком подходе все базы делят один объем памяти, выделенный для этого процесса.rphost использовать свой объем памяти и не достигать 3-4 ГБ лимита, который может приводить к нестабильности и, как следствие, потере взаимодействия с менеджером лицензий.rphost, если это позволяет архитектура системы и лицензия (для КОРП-версий доступны 64-битные компоненты).Этот подход позволяет эффективно управлять памятью и предотвратить сбои, вызванные ее исчерпанием.
Для систем, где сервер 1С:Предприятия работает на виртуальной машине, и аппаратный ключ пробрасывается через USB, мы принимаем дополнительные меры для повышения стабильности:
Для более глубокой диагностики мы используем утилиту HASP License Manager Diagnostic Utility (aksdiag.exe). Эта утилита позволяет нам проверить:
Мы запускаем эту утилиту на сервере и анализируем ее отчеты на предмет любых ошибок или предупреждений, связанных с работой ключа. Также мы внимательно изучаем логи Sentinel License Manager, которые могут содержать записи о попытках доступа к ключу, ошибках инициализации или других проблемах.
Если после всех предпринятых шагов проблема сохраняется, мы составляем подробное обращение в центр лицензирования 1С или в техническую поддержку. В обращении мы:
Sentinel License Manager и, при наличии, данные из утилиты aksdiag.exe.Предоставление полной и точной информации поможет специалистам 1С быстрее локализовать и, возможно, предложить специфическое решение или подтвердить наличие бага.
Таким образом, проблема потери аппаратного ключа на платформе 8.3.16.1063 является комплексной и может быть вызвана рядом факторов. Мы рекомендуем последовательно применять предложенные решения, начиная с наиболее простых и заканчивая более глубокой диагностикой и возможным обращением к вендору. В большинстве случаев откат на предыдущую стабильную версию платформы или настройка автоматического перезапуска служб является эффективным обходным путем.