JP4313858B2

JP4313858B2 - 計算機

Info

Publication number: JP4313858B2
Application number: JP08709198A
Authority: JP
Inventors: 健士門之園; 政行蔵野
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 1998-03-31
Filing date: 1998-03-31
Publication date: 2009-08-12
Anticipated expiration: 2018-03-31
Also published as: JPH11282725A

Description

【０００１】
【発明の属する技術分野】
この発明は、障害検出装置内にあるウォッチドッグタイマを使用してシステム動作監視を行っている計算機に関する。
【０００２】
【従来の技術】
従来から、計算機は、障害が発生すると、その調査に多大な労力を必要とし、この事態を改善することが望まれている。
【０００３】
従来の計算機は、障害検出装置内に設けたウォッチドッグタイマを使用して監視プロセス（ソフトウェア）などからのウォッチドッグタイマ定周期リセット処理（リセット処理と称す）の動作を監視するよう構成されている。
【０００４】
そして、例えば障害発生などによりこのリセット処理が停滞すると、該ウォッチドッグタイムアウトを検出し障害検出装置が高優先度割込み等により計算機を強制的に停止させる。計算機停止の際には、計算機のオペレーティングシステム
（以下ΟＳと称す）が計算機停止ダンプファイルを作成する。
【０００５】
停止した計算機について、オペレータが停止原因を究明する際には、とりあえず、どういう状況で計算機が停止したかを確認するために計算機を起動させて上記ＯＳによって作成された計算機停止ダンプファイルを呼び出し、表示画面上に表示してファイルの中身を一つ一つ解析する。この結果、ウォッチドッグタイマがタイムアウトしたことで計算機が停止したことが判ると、次にタイムアウト発生原因を究明するという手順で順を追って計算機の停止原因を究明して行くことになる。
【０００６】
また、従来の計算機の他の一例としては、障害検出装置内に一つだけ設けたウォッチドッグタイマを使用して異なるスケジュール優先度を持つ複数の監視プロセス（ソフトウェア）などの処理動作をそれぞれの定周期処理部が監視するものもある。
【０００７】
このように異なるスケジュール優先度を持つ複数の監視プロセスの動作を各定周期処理部が監視する場合、高優先度の監視プロセスの定周期処理部がウォッチドッグタイマを定周期リセットすることを障害検出装置が監視し、低優先度の監視プロセスが高優先度プロセスヘ定周期で通信することを高優先度の監視プロセスが監視し、高優先度の監視プロセスが低優先度の監視プロセスの動作停滞を検出したときに、ウォッチドッグタイマ定周期リセット処理を止めるように計算機を構成すると、１つのウォッチドッグタイマで複数のスケジュール優先度のソフトウェア動作を監視することができる。
【０００８】
この計算機の場合、障害発生などによって上記いずれかの監視プロセスの定周期処理動作が停滞すると、障害検出装置内のウォッチドッグタイマがタイムアウトして高優先度割込み等により計算機を強制的に停止させる。
【０００９】
この場合も計算機が停止したときにＯＳによって計算機停止ダンプファイルが作成されるので、オペレータは計算機を起動させた後、計算機停止ダンプファイルを開き、その内容を解析すれば、ウォッチドッグタイムアウト発生およびどのスケジュール優先度の監視プロセスの処理が停滞していたのかを調べることができる。
【００１０】
【発明が解決しようとする課題】
しかしながら、上記計算機においては、いずれの場合も計算機が停止したことの原因究明に、計算機を起動させた後に計算機停止ダンプファイルを呼び出してオペレータがそのファイルの内容を一つ一つ解析して行くしか無く、この解析に多くの時間と労力を要するという問題があった。
【００１１】
また、複数の監視レベルによるシステム動作監視においては、ウォッチドッグタイマ発生の有無だけでなくウォッチドッグタイムアウトが発生した監視レベルがどのレベルであったかということも調べる必要があるが、この際も計算機停止ダンプファイルを解祈するしか方法が無く、計算機の停止原因の究明に多くの時間と労力を要するという問題があった。
【００１２】
本発明はこのような課題を解決するためになされたもので、オペレータが計算機停止ダンプファイルを解析すること無く、計算機の停止原因を速やかに究明することのできる計算機を提供することを目的としている。
【００１６】
【課題を解決するための手段】
上記した目的を達成するために、本発明の計算機は、所定の処理を実行する計算機本体と、一定時間を計時して前記計算機本体を停止させるウォッチドッグタイマと、監視レベルの異なる処理を実行する多段構成の複数の処理手段と、前記各処理手段に設けられ、起動と共に初期値が設定されて所定時間ごとに減数される複数の計数器と、前記各処理手段に各々設けられ、自身が正常に処理を実行しているときは自身よりも優先順位が高い対応する処理手段の計数器あるいは前記ウォッチドッグタイマを再設定する複数の定周期処理部と、前記計数器が、対応する前記定周期処理部により再設定されず前記設定された初期値が減数されて０になった場合、前記監視レベルごとに再設定されなかった旨の情報を監視ステータス情報としてバッファリングする第１のバッファ手段と、前記ウォッチドッグタイマが、対応する前記定周期処理部により再設定されずタイムアウトした場合にそのタイムアウトを示す情報をシステム立ち上げ要因情報としてバッファリングする第２のバッファ手段と、前記計算機本体が起動されたときに前記第１及び第２のバッファ手段にバッファリングされていた情報を基に前記計算機本体の停止原因を判別する停止原因判別手段とを備え、前記処理手段は、前記第１のバッファ手段に対して、前記監視レベルを複数レベルで動作監視する場合に複数レベルによる動作監視であることを示す情報を設定し、さらに、前記複数の定周期処理部が前記監視レベルを複数レベルで動作監視しない場合に、当該複数の定周期処理部の各々が、前記ウォッチドッグタイマの定期的な再設定をそれぞれ行う、ことを特徴とする。
【００１７】
本発明では、１つのウォッチドッグタイマで複数のスケジュール優先度のソフトウェア動作を監視する場合、監視レベルごとに再設定されなかった旨の情報を監視ステータス情報として第１のバッファ手段にバッファリングし、ウォッチドッグタイマがタイムアウトした場合はそのタイムアウト情報をシステム立ち上げ要因情報として第２のバッファ手段にバッファリングしておき、計算機本体がウォッチドッグタイマによって強制停止された後、オペレータなどによって計算機本体が再起動されたときに停止原因判別手段が、第１及び第２のバッファ手段にバッファリングされていた情報を基に計算機本体の停止原因を判別する。
【００１８】
すなわち、監視レベルごとの監視ステータス情報とシステム立ち上げ要因情報とをバッファリングしておくことで、計算機立ち上げ時にソフトウェアから速やかにウォッチドッグタイムアウト発生の有無とウォッチドッグタイムアウトが発生した監視レベルとを確認することができる。
【００１９】
これにより、従来のようにＯＳによって作成された計算機停止ダンプファイルを呼び出してオペレータがそのファイルの内容を解析すること無く、計算機の停止原因を速やかに究明することができる。
【００２０】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して詳細に説明する。
【００２１】
図１は本発明に係る一つの実施形態の計算機の一例を示すブロック図である。
同図において、１は計算機本体である。この計算機本体１には、障害検出装置２、デバイスドライバ３、監視プロセス４、５などの他、制御手段としての所定のオペレーティングシステム（以下ＯＳと称す）やＲＯＭ、ＲＡＭなども搭載されている。この構成例には、複数レベルによる動作監視を行う場合の例を示す。
【００２２】
障害検出装置２は計算機本体１の障害を検出した場合に内部に設定された情報を基に計算機本体１を強制停止するものである。この障害検出装置２には、ウォッチドッグタイマ２１、ウォッチドッグ監視ステータスバッファ２２、システム立ち上げ要因情報バッファ２３などといった記憶手段が設けられている。ウォッチドッグタイマ２１は、計時開始後、再設定（リセット）されることなく所定時間を計時した場合に強制停止信号を計算機本体１に出力し計算機本体１を強制停止させる。所定時間とは、例えば上記各監視プロセス４、５及びデバイスドライバ３の通常の定周期処理に要する時間に若干余裕を持たせた時間である。ウォッチドッグ監視ステータスバッファ２２には、複数レベルによるシステム動作監視の有無やウォッチドッグタイマ２１がタイムアウトしたときの監視レベル情報などが設定される。システム立ち上げ要因情報バッファ２３には、障害検出装置２にて検出されたシステム立ち上げ要因情報がシステム立ち上げ時に設定される。監視プロセス４、５はそれぞれがシステム動作の監視を行う。デバイスドライバ３は、ＯＳの環境下で障害検出装置２を動作させるためのドライバである。デバイスドライバ３には、定周期処理部３１とカウンタ３２とが設けられている。定周期処理部３１はウォッチドッグタイマ２１を上記所定時間内に定期的に再設定（リセット）する処理を実行する。カウンタ３２はデバイスドライバ３の起動と共に定周期処理部３１によって初期値が設定されて定期的にデクリメントされると共に監視プロセス４の定周期処理部４１によって値が再設定される計数器である。監視プロセス４には、上記定周期処理部４１とカウンタ４２とが設けられている。定周期処理部４１はデバイスドライバ３のカウンタ３２を上記所定時間内に定期的に再設定（リセット）する処理を実行する。カウンタ４２は監視プロセス４の起動と共に定周期処理部４１によって初期値が設定されて定期的にデクリメントされると共に監視プロセス５の定周期処理部５１によって値が再設定される計数器である。監視プロセス４、５はそれぞれスケジューリング優先度が異なるシステム動作監視を行うプロセスである。この場合、監視プロセス４のシステム動作監視の優先度は、監視プロセス５のシステム動作監視の優先度よりも高く設定されている。つまり監視プロセス４のスケジューリング優先度は高く監視プロセス５のスケジューリング優先度は低い関係にある。
【００２３】
なお、上記それぞれの定周期処理部３１、４１、５１にて複数レベルによる動作監視を行わない場合は、定周期処理部３１、４１がウォッチドッグタイマ２１を定期的に再設定するようにする（図の点線）。
【００２４】
以下、この計算機の動作について説明する。
【００２５】
この計算機の場合、まず、オペレータが計算機本体１の電源をＯＮすると、計算機本体１内のＯＳが起動し、以下、障害検出装置２、デバイスドライバ３、監視プロセス４、５などが順に起動する。そして、障害検出装置２がウォッチドッグ監視ステータスバッファ２２及びシステム立ち上げ要因情報バッファ２３などの情報をそれぞれ初期化する。
【００２６】
起動した監視プロセス４、５によってシステム動作の監視が開始されると、カウンタ３２、４２、ウォッチドッグタイマ２１に初期値が設定され、デバイスドライバ３がウォッチドッグタイマ２１を起動する。
【００２７】
この実施形態では、複数レベルによるシステム動作監視を行うので、この揚合、デバイスドライバ３よりウォッチドッグ監視ステータスバッファ２２に複数レベルによるシステム動作監視であるという情報が設定されてからウォッチドッグタイマ２１を起動して計時を開始させる。
【００２８】
その後、システムの動作状態が正常であれば、各定周期処理部３１、４１、５１によって、カウンタ３２、４２のデクリメント処理や、カウンタ３２、４２、ウォッチドッグタイマ２１の再設定処理が行われ、監視が継続される。
【００２９】
ここで、例えば監視プロセス５によるスケジューリングが停滞し監視プロセス４のカウンタ４２への再設定処理が行われず、定周期処理部４１によってカウンタ４２がデクリメントされつづけてカウンタ４２の値が０になってしまうと、定周期処理部４１はウォッチドッグ監視ステータスバッファ２２に監視プロセス５のスケジュール優先度のプロセススケジューリングが停滞している旨の情報を設定する。この設定後、定周期処理部４１は処理を停止する。
【００３０】
すると、デバイスドライバ３のカウンタ３２への再設定処理が行われず、定周期処理部３１によってカウンタ３２がデクリメントされつづけてカウンタ３２の値が０になると、定周期処理部３１は監視プロセス４のスケジュール優先度のプロセススケジューリングが停滞している旨の情報をウォッチドッグ監視ステータスバッファ２２に設定し、定周期処理部３１は処理を停止する。
【００３１】
定周期処理部３１が処理を停止すると、ウォッチドッグタイマ２１が再設定（リセット）されなくなり、ウォッチドッグタイマ２１がタイムアウトして、障害検出装置２にてウォッチドッグタイマ２１のタイムアウトが検出されると共に、ウォッチドッグタイマ２１から強制停止信号が出力されて、障害監視装置２によって計算機本体１のシステム動作が強制停止される。
【００３２】
このときに障害監視装置２は、ウォッチドッグ監視ステータスバッファ２２の内容に基づいてシステム立ち上げ要因情報バッファ２３にシステム立ち上げ要因情報を設定する。ウォッチドッグタイムアウトによる再立ち上げであるという情報を設定する。
【００３３】
例えばアプリケーションレベルでの動作異常が発生し、監視プロセス５の動作が滞ると、ウォッチドッグ監視ステータスバッファ２２に監視プロセス４からのスケジューリングが停滞している旨の情報とデバイスドライバ３からのスケジューリングが停滞している旨の情報が設定された後、ウォッチドッグタイマ２１のタイムアウトが発生するため、障害監視装置２はウォッチドッグ監視ステータスバッファ２２の情報を基に、ウォッチドッグタイムアウトによる再立ち上げであるという情報をシステム立ち上げ要因情報バッファ２３に設定する（書き込む）。一方、ハードウェア及びＯＳなどの動作異常によってデバイスドライバ３の動作が滞ると、ウォッチドッグ監視ステータスバッファ２２に情報が設定されずにウォッチドッグタイムアウトが発生するため、障害監視装置２はウォッチドッグ監視ステータスバッファ２２の情報を基に、ハードウェア及びＯＳなどの動作異常による再立ち上げであるという情報をシステム立ち上げ要因情報バッファ２３に設定する（書き込む）。
【００３４】
以下、図２を参照して計算機を再起動させたときの動作を説明する。
【００３５】
停止した計算機の電源をオペレータがＯＮすると（ステップS100）、計算機本体１のＯＳが起動する。
【００３６】
そして、ＯＳは、自身の環境下で障害検出装置２、デバイスドライバ３及び各監視プロセス４、５を起動すると、まず、システム立ち上げ要因情報バッファ２３を参照し、システム立ち上げ要因情報２３にウォッチドッグタイムアウトによる再立ち上げであるという情報が設定されているかどうかを調べる（ステップS101）。この判断結果でウォッチドッグタイムアウト発生の有無を判定できる。例えば再立ち上げで無ければ（ステップS101のNo）、ウォッチドッグタイムアウトは発生していないと判別する（ステップS102）。
【００３７】
また、ウォッチドッグタイムアウトによる再立ち上げであれば（ステップS101のYes ）、次にＯＳは、ウォッチドッグ監視ステータスバッファ２２の内容を参照し、ウォッチドッグ監視ステータスバッファ２２に複数レベルによるシステム動作監視の情報が設定されているか否かを調べる（ステップS103）。
【００３８】
ここで、複数レベルによるシステム動作監視の情報が設定されていなければ（ステップS103のNo）、ウォッチドッグタイムアウトと判別する（ステップS104）。
【００３９】
また、ウォッチドッグ監視ステータスバッファ２２に複数レベルによるシステム動作監視の情報が設定されていた場合（ステップS103のYes ）、次にＯＳは、監視プロセス４からの情報がウォッチドッグ監視ステータスバッファ２２に設定されているかどうかを判断する（ステップS105）。
【００４０】
ここで、監視プロセス４からの情報が設定されていれば（ステップS105のYes ）、監視プロセス５の動作不可によるユーザレベルのウォッチドッグタイムアウトと判別する（ステップS106）。
【００４１】
また、監視プロセス４からの情報が設定されていなかった場合（ステップS105のNo）、次にＯＳは、デバイスドライバ３からの情報がウォッチドッグ監視ステータスバッファ２２に設定されているかどうかを判断する（ステップS107）。
【００４２】
ここで、デバイスドライバ３からの情報が設定されていれば（ステップS107のYes ）、監視プロセス４の動作不可によるユーザレベルのウォッチドッグタイムアウトと判別する（ステップS108）。
【００４３】
また、監視プロセス４からの情報が設定されていなかった場合（ステップS107のNo）、ＯＳは、カーネルレベルのウォッチドッグタイムアウトと判別する（ステップS109）。ここでカーネルレベルとはＯＳあるいはハードフェアのレベルである。
【００４４】
このようにＯＳは、ステップS105,S107 それぞれの判断処理の結果でウォッチドッグタイムアウトの監視レベルの切り分けを行う。つまりウォッチドッグタイマ２１がタイムアウトした監視レベルがどのレベルかを判定する。
【００４５】
このように各処理にて判別した結果は、計算機１の表示画面上に計算機本体１の停止原因として表示され、オペレータに通知される。
【００４６】
このようにこの実施形態の計算機によれば、計算機本体１が停止されるときに、システム立ち上げ要因情報バッファ２３にシステム立ち上げ要因情報が記憶され、計算機本体１を再起動したときに、ＯＳによって自動的にシステム立ち上げ要因情報バッファ２３内のシステム立ち上げ要因情報が読み込まれて計算機本体１の停止原因についての詳細な判別処理が実行されて、例えばウォッチドッグタイムアウトによるものか、ハードフェア及びＯＳ的な原因によるものかが表示されるので、さまざまな停止原因がある中で、初めに確認すべき２大要因（ソフトウェア的な停止であるか、ハードフェア及びＯＳ的な停止であるか）が即座に判るので、オペレータは、計算機本体１の停止原因を速やかに究明することができる。この結果、オペレータは、計算機停止ダンプファイルを一々解析すること無くウォッチドッグタイムアウト発生の有無などを確認できる。
【００４７】
また、複数レベルによるシステム動作監視を行っているときには、計算機停止時にシステム立ち上げ要因情報バッファ２３に監視レベル毎にシステム立ち上げ要因情報が記憶され、再起動時にＯＳがウォッチドッグタイムアウトを監視レベル毎に判別するので、ウォッチドッグタイムアウトが発生した監視レベルも同時に確認できる。
【００４８】
【発明の効果】
以上説明したように本発明によれば、計算機を停止させたときにその時点の監視内容がバッファリングされ、計算機を再起動させたときに計算機自身がバッファリングされた内容を基に詳細な停止原因を判別するので、ウォッチドッグタイムアウト発生が有ったためであるか否かを速やかに判別することができる。
【００４９】
また、複数レベルによるシステム動作監視を行っている場合も、ウォッチドッグタイムアウトの発生原因を監視レベル毎に判別するので、どの監視レベルでウォッチドッグタイムアウトが発生したかも確認することができる。
【００５０】
この結果、オペレータが計算機停止ダンプファイルを解析すること無く、計算機の停止原因を速やかに究明することができる。
【図面の簡単な説明】
【図１】この発明に係る一つの実施形態の計算機の構成を示すブロック図である。
【図２】この計算機における障害検出装置の動作を示すフローチャートである。
【符号の説明】
１…計算機本体、２…障害検出装置、３…デバイスドライバ、４、５…監視プロセス、２１…ウォッチドッグタイマ、２２…ウォッチドッグ監視ステータスバッファ、２３…システム立ち上げ要因情報バッファ、３２、４２…カウンタ、３１、４１、５１…定周期処理部。

Claims

所定の処理を実行する計算機本体と、
一定時間を計時して前記計算機本体を停止させるウォッチドッグタイマと、
監視レベルの異なる処理を実行する多段構成の複数の処理手段と、
前記各処理手段に設けられ、起動と共に初期値が設定されて所定時間ごとに減数される複数の計数器と、
前記各処理手段に各々設けられ、自身が正常に処理を実行しているときは自身よりも優先順位が高い対応する処理手段の計数器あるいは前記ウォッチドッグタイマを再設定する複数の定周期処理部と、
前記計数器が、対応する前記定周期処理部により再設定されず前記設定された初期値が減数されて０になった場合、前記監視レベルごとに再設定されなかった旨の情報を監視ステータス情報としてバッファリングする第１のバッファ手段と、
前記ウォッチドッグタイマが、対応する前記定周期処理部により再設定されずタイムアウトした場合にそのタイムアウトを示す情報をシステム立ち上げ要因情報としてバッファリングする第２のバッファ手段と、
前記計算機本体が起動されたときに前記第１及び第２のバッファ手段にバッファリングされていた情報を基に前記計算機本体の停止原因を判別する停止原因判別手段とを備え、
前記処理手段は、前記第１のバッファ手段に対して、前記監視レベルを複数レベルで動作監視する場合に複数レベルによる動作監視であることを示す情報を設定し、
さらに、前記複数の定周期処理部が前記監視レベルを複数レベルで動作監視しない場合に、当該複数の定周期処理部の各々が、前記ウォッチドッグタイマの定期的な再設定をそれぞれ行う、
ことを特徴とする計算機。