test

Sun Java System Calendar Server 6 2005Q4 管理ガイド

Procedurecsadmind が起動しない、または起動時にクラッシュする

csadmind では GSE (グループスケジューリングエンジン) とアラームディスパッチエンジンの両方のサービスを処理するため、GSE キュー内、またはアラームキュー内のエントリに問題があると、これらの問題が発生する可能性があります。

対応策

手順

  1. csadmind が稼動していない場合は、すぐに stop-cal を実行します。

    カレンダサービスを稼動したままにしておくと、トランザクションログが累積し、それが原因でデータベースがさらに破損して、トランザクションログファイルとデータベースを照合するのに時間がかかる場合があります。

  2. csadmind の再起動を試みます (start-cal の再実行)。

    正常に起動したら、次のようにして 2 つのキューが機能していることを確認します。

    1. csschedule を使用して、GSE キューをチェックします。

    2. dbrig を使用して、アラームキューをチェックします。

      csschedule および dbrig の実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。

  3. csadmind がダンプでクラッシュした場合は、pstack を分析します。

    トレースに GSE に関連した機能がある場合は (中に GSE の文字がある)、GSE キューの最初のエントリおよび予定データベースの参照エントリを調べます。ほとんどの場合、GSE エントリで参照されている予定が、問題を起こしているエントリです。この問題を解決するには次を実行します。

    1. csschedule を使用して、GSE エントリを削除します。

    2. cscomponents を使用して、問題を起こしている予定をデータベースから削除します。

      csschedule および cscomponents の実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。

  4. エントリが破損していない場合は、カレンダサーバーでは処理できない特殊な例の可能性があります。

    次の手順を実行します。

    1. 破損したデータベースのカレンダ環境のスナップショットを取り、カスタマサポートに問い合わせます。

      環境のバックアップを作成するには、次のように実行します。

      1. 次の場所にある db_checkpoint ユーティリティーを使用します。

        cal_svr_base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint

      2. db_archive -s を実行します。

        -s オプションを使用して、すべてのデータベースファイルを識別し、それらを CD、DVD、テープなどのリムーバブルメディアにコピーします。

      3. db_archive -l を実行します。

        -l オプションを使用して、すべてのログファイルを識別し、使用されていないファイルをリムーバブルメディアデバイスにコピーします。

    2. サービスの停止を避けるには、カレンダデータベースを一時的に読み取り専用の状態にして、ホットバックアップのコピーに戻ります。

      • カレンダデータベースを一時的に読み取り専用の状態にすると、トランザクションの追加、変更、または削除はできなくなります。エンドユーザーがカレンダデータを追加、変更、または削除しようとすると、エラーメッセージが表示されます。カレンダの予定および仕事を追加、変更、または削除する管理者ツールも、データベースが読み取り専用モードの間は機能しません。

        カレンダデータベースを読み取り専用モードにするには、ics.conf ファイルを編集して、次のパラメータを “yes” に設定します。

        caldb.berkeleydb.readonly=”yes”

      • 「自動バックアップコピーの復元」にある手順を使用して、ホットバックアップコピーに戻ります。

        csstored を設定して有効にすると、ホットバックアップが使用可能になり、数分以内に最新の状態になります。また、常にホットバックアップコピーを検証して、破損していないことを確認するとよいでしょう。その場合は、db_verify を実行します。

  5. ほかの方法がすべて失敗した場合、ダンプと再ロードの手順を実行して、データベースを修復できるかどうか確認します。

    この手順は、「ダンプとロードによるカレンダデータベースの復元」で説明しています。