locked
Windowsサービスの”回復”タブ機能につきまして RRS feed

  • 質問

  • 「Windows2008R2」を利用しており、定期イベントとしてOS再起動を行った際に稼働中の「SQLServer2008R2」が稀に正常起動しないケースがある為、即時復旧を目的として該当サービスの"回復"タブの「サービス再起動」設定を利用したいと検証環境で試行しております。
    該当サービス(MSSQLServer)の"回復"タブ上から下記の設定を加えて適用しました。

    「最初のエラー 」:サービスを再起動する
    「次のエラー  」:サービスを再起動する
    「その後のエラー」:サービスを再起動する
    「エラーカウントのリセット」:1日後に行う
    「サービスの再起動」:3分後に行う
    「エラーで停止したときの操作を有効にする」:有効

    サービスコンソールやnet、scコマンドを利用した停止処理では「正常終了」となります。
    そこで意図的に障害を起こす為、下記方法を試行しましたが"回復"タブによるサービス再起動は動作しませんでした。

    (1).該当サービスのログオンアカウントのパスワードを意図的に間違えて設定し、OS再起動する。
    (2).レジストリ値"ServicesPipeTimeout"を新規追加し、SCMのサービス起動待機時間を短くし、意図的に該当サービスがタイムアウトで起動失敗するようにして、OS再起動する。

    それぞれの終了コードは「ERROR_INVALID_SERVICE_ACCOUNT 1057」、「ERROR_SERVICE_REQUEST_TIMEOUT 1053」となり、サービス再起動が行われると想定しておりましたが全く処理しませんでした。

    上記のような擬似障害では、"回復"タブの機能確認を行うことはできないのでしょうか?
    例えば、タスクマネージャからプロセスを強制終了させるなどの荒技が必要でしょうか?
    Windowsサービスの"回復"タブ設定につきまして、何か解決策があれば是非ともご教示下さい。

    2013年10月25日 10:49

回答

  • 旧 Windows の場合、および、Vista 以上の Windows で sc qfailureflag で照会されるフラグが立っていない場合、「回復」の対象になるのは、サービスをホストしているプロセスがクラッシュしたときです。(1)の場合も(2)の場合も、サービス コントロールがエラーとなったときには、プロセスがクラッシュしたかどうかの監視がまだ始まっていません。監視が始まるのはサービスがコントロール用パイプへ接続した後なので、「回復」対象となるには、そこまでは処理が成功する必要があると思います。

    • 編集済み HomeCloset 2013年10月26日 13:42 追記
    • 回答の候補に設定 佐伯玲 2013年10月28日 2:00
    • 回答としてマーク 佐伯玲 2013年10月29日 7:47
    2013年10月26日 13:16

すべての返信

  • 旧 Windows の場合、および、Vista 以上の Windows で sc qfailureflag で照会されるフラグが立っていない場合、「回復」の対象になるのは、サービスをホストしているプロセスがクラッシュしたときです。(1)の場合も(2)の場合も、サービス コントロールがエラーとなったときには、プロセスがクラッシュしたかどうかの監視がまだ始まっていません。監視が始まるのはサービスがコントロール用パイプへ接続した後なので、「回復」対象となるには、そこまでは処理が成功する必要があると思います。

    • 編集済み HomeCloset 2013年10月26日 13:42 追記
    • 回答の候補に設定 佐伯玲 2013年10月28日 2:00
    • 回答としてマーク 佐伯玲 2013年10月29日 7:47
    2013年10月26日 13:16
  • ご回答ありがとうございました。

    今件はサービスコントロールでのエラーである為、プロセスクラッシュへの監視が行われる以前の問題であり、サービスの回復オプションは有効策でないと認識しました。別途、サービス監視用のバッチなどで対処したいと思います。

    因みに適当なサービスで”回復”タブを設定し、サービス"開始"後にタスクマネージャ上からプロセス強制停止したところ、当初に希望していた通りの動作が行われることも確認できました。

    2013年10月29日 5:28