XenAppのポリシーを使ってWindows Server 2008 R2を自動的に再起動しているのですが、何故か再起動ではなくシャットダウンしてしまう現象に遭遇しています。発生頻度は週に１～２台くらいなのでサービス全体への影響はありません。とあるサービスのエラーがシャットダウンの原因だったので詳細を記載します。
ユーザーサービスへの影響
日中にユーザーが使用して残留しているメモリのリフレッシュや、OSの健全な動作を目的として、夜間にXenAppサーバーを再起動しています。そこで何故か再起動せずにシャットダウンする事象がちらほら発生します。複数のXenAppサーバーでサービスを提供しているので、全体のパフォーマンスには影響しませんが、気持ち悪いのでそのうち調べようと考えていました。なんせ忙しいので取りあえず起動して動作に問題がなさそうだったのでイベントログも見ずに放置ですよ。管理者として最悪ですな。。。
Windowsのファットダウンフローから原因を予想する
Windowsのシャットダウンの流れは、アプリケーションの終了→ドライバやサービスの終了→最後にハードウェアに対し電源オフやリセットの信号を出して電源オフという流れです。
サーバー運用の部署に異動する前はクライアントPCの保守作業を担当していました。その時に、サービスが終了する前に電源オフ信号が出てしまい、毎回チェックディスクが実行されるという問題に遭遇したことを思い出しました。この経験から問題の原因を予想します。
サービスが落ちる前にリセット信号が出ているなら、イベントログに不正なシャットダウンが記録されていることが予想されますので、後でイベントログを確認します。
通常のクライアントPCの場合不正なシャットダウンが記録されると自動的に再起動しメモリダンプを取得する設定がデフォルトです。しかし、サーバーOSの場合は勝手に再起動されると困る場合が多いので、不正シャットダウン時の自動再起動はデフォルトで無効になっています。
予想した原因
サービスなりドライバが正常終了する前にハードリセットが実行される
↓
不正シャットダウンのフラグが記録される
↓
不正シャットダウン時は再起動しない設定になっている
↓
永遠の眠りにつく
現象からの推定ですが矛盾点は無さそうです。
予想の裏付け確認
イベントログを確認すると、［ID:41 Kernel-Power、ID:1001 BugCheck］が記録されています。やはり不正なシャットダウンが発生している様です。
コレが分かればシャットダウン信号を遅延させるレジストリを設定すれば良いわけです。って事でネットで該当するレジストリを調べました。
修正パッチが見つかる
Google先生にイベントログのIDを伝えたところ、マイクロソフトに次のナレッジが存在する事を教えてくれました。
「レジストリの WaitToKillServiceTimeout 値は Windows 7 または Windows Server 2008 R2 で機能しません。」
まさに今回の現象そのままです。なんや、答え載ってるやん・・・
本現象はOSのバグによるものだそうで、Hotfixを適用すれば対策完了です。もしまだ現象が残る様ならレジストリで「WaitToKillServiceTimeout」の値を伸ばして対応すれば良さそうです。
コメント