Проблема с установщиком Wix: почему RestartManager помечает Service как RMCritical, а не RMService
Я пытаюсь запретить нашим установщикам wix запрашивать перезагрузку при удалении. Наши услуги должны быть удалены и удалены при удалении. К сожалению, для нас RestartManager подсказывает пользователю, что во время действия InstallValidate потребуется перезагрузка. Это действие происходит задолго до действий StopServices и DeleteServices.
Проверяя журналы, кажется, что RestartManager считает, что наш сервис является критическим процессом:
"Обнаружено приложение с идентификатором 1234, понятным именем" abc ", коротким именем службы" xyz ", типом RmCritical и статусом 1 содержит файлы [s] в использовании".
Службы установлены и работают под локальной системной учетной записью. Я не уверен, но я думаю, что если RestartManager возвращал RmService вместо RmCritical, то это не было бы причиной перезагрузки.
Любая помощь высоко ценится.
РЕДАКТИРОВАТЬ: MSDN утверждает, что для RMCritical: перезагрузка системы требуется для завершения установки, потому что процесс не может быть остановлен. Процесс не может быть остановлен по следующим причинам. Процесс может быть критическим процессом. Текущий пользователь может не иметь разрешения на завершение процесса. Процесс может принадлежать основному установщику, который запустил менеджер перезапуска.
У пользователя есть разрешение на отключение сервисов, и сервисы не имеют ничего общего с msiexec, поэтому я могу только предположить, что наш сервис считается критическим процессом.... но почему?
3 ответа
Вы можете отключить RestartManager в окне, установив свойство MSI MSIRESTARTMANAGERCONTROL= "Disable" (см. Документацию здесь - http://msdn.microsoft.com/en-us/library/windows/desktop/aa370377(v=vs.85).aspx). Единственная проблема с этим подходом сама по себе состоит в том, что вместо того, чтобы предлагать пользователям диалоговое окно с требованием перезагрузки, они увидят диалоговое окно с файлом при использовании (и попросят закрыть все приложения, которые могут использовать эти файлы / сервисы). Это диалоговое окно отображается во время стандартного действия InstallValidate последовательности InstallExecute.
Если вы хотите незаметно обойти любое из этих диалогов, вы можете запланировать настраиваемое действие перед InstallValidate, которое вручную отключит все работающие службы, прежде чем RestartManager сможет осмотреть систему. Это не соответствует стандартным практикам MSI, потому что обычно вы отмечаете настраиваемое действие, которое изменяет систему как "отложенное" действие, но MSI не разрешает запуск каких-либо отложенных действий до InstallValidate. Таким образом, вам нужно будет пометить действие как "немедленное", но в коде вы продолжите и измените систему, закрыв службы. Недостатком здесь является то, что не существует такой вещи, как немедленное действие отката, поэтому, если при удалении / обновлении происходит сбой и происходит откат, остановленные вами сервисы останутся в остановленном состоянии. Положительным моментом является то, что пользователям никогда не нужно видеть никаких дополнительных диалогов во время их удаления / обновления.
Наткнулся на это тоже.
Проблема в том, что менеджер перезапуска НЕ считает, что у пользователя есть разрешение на остановку службы, даже если это происходит, потому что во время проверки (InstallValidate) установка еще не была повышена.
Мое решение - дать группе пользователей разрешение на запуск и остановку службы. Я использовал sc sdset Команда для изменения разрешения службы.
Или вы можете использовать загрузчик, чтобы запустить MSI после повышения.
Диспетчер перезапуска обычно не запрашивает какие-либо ситуации использования файлов для служб, помеченных для остановки в текущей операции. Другими словами, он просматривает таблицу ServiceControl, чтобы узнать, будет ли служба остановлена в любом случае, и не будет автоматически запрашивать используемые файлы.
К сожалению, это поведение однажды было скомпрометировано ошибкой - проверялась только первая запись в таблице ServiceControl. Я не знаю, была ли эта ошибка когда-либо задокументирована, поэтому я не могу ничего цитировать. Оригинальный вопрос был опубликован в 2011 году, поэтому я предполагаю, что этот конкретный вопрос был исправлен. Единственными проблемами такого рода, которые возникают в настоящее время, являются, как правило, ситуации, когда сервис в некотором смысле является многопроцессорным, или в оболочке (некоторые java-сервисы похожи на этот) или когда сервис действительно перестает быть сервисом, но содержащийся процесс не завершить быстро, или ServiceControl не делает полного ожидания, и он все еще фактически работает.