Calendar Server のトラブルシューティング

ここでは、データベース以外の問題のさまざまなトラブルシューティングについて説明します。ここで説明する内容は次のとおりです。

• 「カレンダサービスに対する ping の実行」

• 「start-cal の問題の解決」

• 「stop-cal の問題の解決」

• 「バックエンドサーバーに接続できない」

• 「カレンダが見つからない」

• 「プロキシ認証を使用してログインしようとすると「承認されていない」が表示される」

• 「正しく完了しない検索のトラブルシューティング」

• 「csstored のわずらわしい日常的なメッセージを無効にする」

---

ヒント –

さらに、次の SSL の章にも、SSL に関するトラブルシューティングの節があります。

「SSL のトラブルシューティング」

---

カレンダサービスに対する ping の実行

サービスが特定のポート番号で待機していることを確認するには、「cstool」 ユーティリティーの ping コマンドを実行します。サービスに対して ping を実行しても、サービスが実際に稼動しているかどうかは検証されません。ソケット接続が受け付けられるかどうかが検証されます。

cstool のサービスオプション

Calendar Server サービスには次のオプションがあります。

http

HTTP サービス (cshttpd)

admin

管理サービス (csadmind)

ens

ENS (予定通知サービス) (enpd)

---

注 –

DWP サービス (csdwpd) や通知サービス (csnotifyd) に対して ping を実行することはできません。

---

cstool の例

たとえば、calserver というホスト名のマシンに対して ping を実行し、cshttpd サービスがポート 80 で待機しているかどうかを確認するには、次のように実行します。

cstool -p 80 -h calserver ping http

デフォルトでは、cstool は 120 秒間応答を待ちますが、-t timeout オプションを使用してこの値を変更することができます。

ユーティリティーの詳細な参考資料については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。

---

注 –

cstool を実行するには、Calendar Server が稼動している必要があります。

---

start-cal の問題の解決

start-cal を実行したときに起動しないカレンダサービスがある場合は、再起動する前に起動したサービスを終了する必要があります。たとえば、enpd、csnotifyd、および csadmind が起動しても cshttpd が起動しなかった場合は、enpd、csnotifyd、および csadmind を終了する必要があります。

カレンダサービスを起動するには、次のように実行します。

手順

1. Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインします。

2. サービスを終了して、再起動するには、start-cal を使用します。次に例を示します。

   cal_svr_base/SUNWics5/cal/sbin/start-cal

   start-cal は、さまざまなカレンダサービスを起動する前に、まず stop-cal コマンドを実行します。

3. stop-cal が終了に失敗した場合は、いくつかの子プロセスが終了に失敗した可能性があります。この場合の処理については、「stop-cal の問題の解決」を参照してください。

stop-cal の問題の解決

Calendar Server のシャットダウン時には、考慮する必要がある 2 つの別個の問題があります。

• 「子プロセスを停止するには」

• 「不正シャットダウンしたあとで回復するには」

子プロセスを停止するには

stop-cal を実行したあと、いくつかの子プロセスが停止していない場合があります。たとえば、stop-cal によって cshttpd 親プロセスは停止しているのに、一部の cshttpd 子プロセスが停止していないことがあります。このような場合は、次の手順で、残りの Calendar Server プロセスを個別に停止させる必要があります。

手順

1. Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインします。

2. サービスごとに ps コマンドを実行し、残っている Calendar Server プロセスのプロセス ID (PID) を特定します。

   ps -elf | grep cs-process

   ここで、cs-process は enpd、csnotifyd、csdwpd、csadmind、または cshttpd です。次に例を示します。

   ps -elf | grep cshttpd

3. kill -15 コマンドに終了していない各プロセスの PID を指定して、プロセスを終了します。例: kill -15 9875

4. それぞれの ps コマンドをもう一度実行し、すべての Calendar Server プロセスが終了していることを確認します。

   Calendar Server プロセスがまだ稼動しているときは、kill -9 コマンドを実行して終了します。例: kill -9 9875

   ---

   注 –

   Linux システムで Calendar Server を実行していて、ps コマンドを使用してカレンダプロセスを検索すると、結果がわかりにくく見えることがあります。Linux では、ps コマンドは、プロセスのリストではなく実行しているスレッドのリストを返します。プロセスだけが表示されるようにするための既知の解決策はありません。

   ---

不正シャットダウンしたあとで回復するには

Calendar Server が正しくシャットダウンしなかった場合は、次の手順を実行します。

手順

1. 前の手順 (「stop-cal の問題の解決」) を実行します。

2. LDAP データキャッシュデータベースのディレクトリ内のすべてのファイルを手動で削除します。

   ファイルが残っていると、データベースが破損する可能性があります。ファイルを削除するには、次のように実行します。

   1. LDAP データキャッシュのディレクトリに移動します。

      デフォルトでは /opt/SUNWics5/csdb/ldap_cache ですが、ics.conf ファイルの local.ldap.cache.homedir.path パラメータで指定されるディレクトリを使用してください。

   2. ディレクトリ内のすべてのファイルを削除します。

      例: rm *.*

   3. すべてのファイルが削除されたことを確認します。

      例: ls

3. Calendar Server を再起動します。

   cal_svr_base /SUNWics5/cal/sbin/start-cal

   LDAP データキャッシュの設定方法については、「Calendar Server の LDAP の設定」を参照してください。LDAP データキャッシュについては、『Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide』を参照してください。

バックエンドサーバーに接続できない

1. 応答しているかどうか調べるには、バックエンドサーバーに対して ping を実行します。

   応答している場合は、手順 3 に進みます。応答していない場合は、その原因を調べ、ふたたび動作するようになったら手順 3 に進みます。

2. CLD キャッシュをクリアします。「CLD キャッシュのクリア」を参照してください。

   CLD キャッシュオプションを使用していて、ics.conf パラメータのサーバー名を更新した場合は、CLD キャッシュをクリアしてサーバー名を消去するとよいでしょう。CLD キャッシュに古いエントリが残されていると、フロントエンドサーバーが正しいバックエンドサーバーに接続できなくなったり、Calendar Server が移動後のカレンダを見つけられなくなります。

3. Calendar Server を再起動します。

カレンダが見つからない

CLD キャッシュオプションを使用していて、1 つ以上のカレンダを別のバックエンドサーバーに移動した (または、バックエンドサーバーの名前を変更した) 場合は、次の手順を実行します。

1. 次に記載されている手順に従ってカレンダを移動していることを確認します。

   「ユーザーカレンダの管理」を参照してください。

2. CLD キャッシュをクリアします。「CLD キャッシュのクリア」を参照してください。

   1 つ以上のカレンダを別のバックエンドサーバーに移動すると、CLD キャッシュは無効になります。再読み込みするには、キャッシュをクリアする必要があります。そうすると、キャッシュが再構築されます。

プロキシ認証を使用してログインしようとすると「承認されていない」が表示される

1. service.http.allowadminproxy が “yes” に設定されていることを確認します。

2. admin-user に Calendar Server 管理者の権限があることを確認します。

3. admin-password が正しいことを確認します。

4. calendar-user が有効な Calendar Server ユーザーであることを確認します。

正しく完了しない検索のトラブルシューティング

LDAP ディレクトリサーバー設定の nsslapd-sizelimit 属性と nsLookthroughLimit 属性は、検索が正しく終了するように十分なサイズに設定する必要があります。nsSizeLimit が十分なサイズでない場合は、一部の結果が欠落したり、検索結果が表示されなくなることがあります。nsLookthroughLimit が十分なサイズでない場合は、検索が完了しないことがあります。

ここで説明する内容は次のとおりです。

• 「制限属性の値が適切かどうかを調べるには」

• 「制限属性を適切な値に設定するには」

制限属性の値が適切かどうかを調べるには

手順

1. これらの属性に適切な値が設定されているかどうかを調べるには、次のコマンドを実行します。

   ldapsearch -b "base " "(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"

   ここで、base は、Calendar Server のユーザーとリソースのデータが格納されているディレクトリサーバーの LDAP ベース DN であり、user は、エンドユーザーがユーザーインタフェースの検索ダイアログで入力できる値です。

2. LDAP サーバーがエラーを返す場合、nsSizeLimit または nsLookthroughLimit パラメータの値が十分でない可能性があります。

制限属性を適切な値に設定するには

これらの属性の DN は次のとおりです。

dn: cn=config,cn=ldbm databases,cn=plug ins,cn=config

手順

1. nsLookthroughLimit の値を動的に設定するには、ldapmodify を使用します。

   この属性を変更するために Directory Server を終了して再起動する必要はありません。

   デフォルト値は 5000 です。検索結果が表示されない場合、この値を大きくすることができます。ただし、そうすると LDAP サーバーのパフォーマンスが低下します。

   制限を -1 に設定して、制限の適用を解除することもできます。ただし、システムがハングすることが想定されるため、慎重に行ってください。

2. nsslapd-sizelimit をより大きい値に設定する場合は、次の手順を実行する必要があります。

   1. Directory Server を停止します。

   2. dse.ldif ファイルを編集します。

   3. Directory Server を再起動します。

      ---

      注 –

      ldapmodify の使用方法および dse.ldif ファイルの編集方法については、次の Web サイトで入手できる Directory Server のマニュアルを参照してください。

      http://docs.sun.com/coll/1316.1

      ---

csstored のわずらわしい日常的なメッセージを無効にする

start-cal コマンドは、csstored プロセスが設定されていない場合でも、デフォルトで csstored プロセスを起動します。設定されていない csstored プロセスは、csstored を実行しているすべてのマシンで 24 時間ごとに設定されていないことを伝えるメッセージを出力します。

csstored を未設定の状態で実行しないようにすることによって、メッセージを無効にできます。csstored プロセスの実行を無効にするには、メッセージが生成されるすべてのマシンで、次の ics.conf パラメータを設定します。

service.store.enable=”no”

自動バックアップ作成のために csstored を設定しているマシンでは、プロセスを無効にしないでください。