RestartManager导致辅助角色重新启动 [英] RestartManager causes worker role to restart

查看:93
本文介绍了RestartManager导致辅助角色重新启动的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

最近,我们遇到了Azure工作者角色服务几乎每天都重新启动的问题.这对我们来说是一个巨大的问题,因为我们的服务大约需要20分钟才能初始化,而这些重启会导致停机.
我通过RDP登录到实例,并查看了事件日志以找出是什么原因导致了这些看似随机的重启.我遇到了一些总是在重启之前出现的条目:

lately we encountered the problem that our Azure Worker Role service restarts almost every day. This is a huge problem for us, since our service needs around 20 minutes to initialize and these restarts can cause downtimes.
I logged in to the instances via RDP and looked in the event logs to figure out what was causing these seemingly random restarts. I came accross a few entries that always preceded a restart:

MsiInstaller安装的服务是"Windows Azure远程转发器".我假设已安装此服务,因为我们在工作人员角色配置中启用了远程桌面.有趣的是,我们启用RDP的时间很长(大约2年),但是从4周前开始随机重启.
但是有些事情我还不太了解:

The service installed by the MsiInstaller is "Windows Azure Remote Forwarder". I assume this service gets installed because we enabled Remote Desktop in our worker role configuration. The interesting thing is that we have RDP enabled for a long time (2 years or so) but the random restarts are just occuring since 4 weeks ago.
But there are a few things than I don't quite understand:

  1. 为什么如此频繁地安装或更新此服务?
  2. 我知道RestartManager负责安装/更新服务,而不必通过停止阻止文件的其他服务来重新启动计算机.
    我们的服务可能会阻止一些重要文件吗?
    我们将本地磁盘存储用于临时文件可能会出现问题吗?
  3. 是否可以告诉RestartManager单独保留我们的工作者角色服务?
  4. 这只是巧合,重启是由我们的服务触发的,尽管没有日志表明我们这边有错误?

任何帮助将不胜感激.

谢谢,
卡斯滕

推荐答案

自我修复 :您看到的很可能是Windows Installer的自我修复.如果文件被意外修改,这是一种将文件放回原处的机制,但是此原始目的可能会引发很多问题,并导致无休止的修复循环-这可能就是这里发生的情况. 很可能已经安装了另一种产品,并且现在存在无法修复的错误情况,该错误情况会触发通过MSI自修复进行的持续且失败的修复尝试.必须通过日志记录和事件查看器调试来识别冲突情况,并且必须应用适当的修复程序 ( Terse解释 :以下是关于自我修复或复原力"真正含义的最简洁的解释: 为什么如果我删除文件,MSI安装程序会重新配置吗?

Terse Explanation: Here is the most condensed explanation of what self-repair or "resilience" really is about that I have: Why does the MSI installer reconfigure if I delete a file?

重启管理器 : 重启管理器功能> 是-正如您自己说过(其他人可能会读)-只是安装程序重新启动应用程序的一种方式,而无需通过使应用程序能够自行关闭并以受控方式重新启动"来重新启动系统.

  • 发生的情况很可能是您的服务无法使用其本机启动/停止过程及时关闭-或MSI不尝试使用内置的MSI服务控制机制来重新启动服务. 您的服务无法及时停止或完全停止 .也许.我想这可能会触发重新启动管理器事件.当然,如果将REINSTALLMODE设置为 "amus" -强制覆盖所有文件,而不考虑版本.
  • 似乎这里的人是开发人员,也许是有关如何在您的应用程序中实现Restart Manager支持的技术示例: 如何在应用程序中添加对Windows Restart Manager的支持? ( 很多重新启动管理器链接和信息 (中页)

默认MSI日志记录 :一个调试起点是 部分中的过程来启用所有MSI安装的日志记录.

Default MSI Logging: One debugging starting point is to log all your MSI operations properly - whenever you install, reinstall or repair there will be a log file in the temp directory (not always acceptable for some sysadmins). You can enable logging for all MSI installations by following the procedure in the "Globally for all setups on a machine" section in the above link.

详细的自我修复 :之前我写过很多关于意外的自我修复的文章.比任何人都想知道的更多.由于很少有人熟悉Windows Installer的操作,因此这确实是一个非常愚蠢的问题,确实会导致解决非常昂贵的问题:

Self-Repair in Detail: I have written a lot about unexpected self-repair before. More than anyone wants to know. It is a terribly silly problem that does cause really expensive problems to resolve since few people are familiar with the operation of Windows Installer:

  1. 自我修复-解释
  2. 自我修复-找到现实的解决方案
  3. 自我修复-如何避免在自己的包装中使用它


调试 :上面的答案提供了以下所有信息,但是这里有一些快速提示:


Debugging: All the information below is available in the above answers, but here are some quick pointers:

  • You can determine the exact MSI component that triggers the repair using the following approach: http://www.installsite.org/pages/en/msifaq/a/1037.htm.
  • Open the Event Viewer and look in "Applications" for warnings with event source "MsiInstaller": IDs 1001 and 1004.
  • Some recent installation of another package could trigger a constant error situation that can not be resolved permanently during repair and you must identify the source and eliminate it somehow. The item two link above (repeated here: finding real-world solutions).

待重新启动 :这台计算机多长时间重启一次?许多机器都注册了许多挂起的重启,这些重启从未完成,并且可能导致问题.触发重新启动(警告)可能涉及许多注册表位置. Get-PendingReboot-Query .还有类似的PowerShell脚本.

锁定问题 :只想提及 查看全文

登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆