test

Sun Java System Calendar Server 6.3 管理ガイド

22.4 Calendar Server でのデータベース以外のトラブルシューティング

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

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

ヒント –

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

「7.2 Calendar Server 6.3 ソフトウェアの SSL のトラブルシューティング」

22.4.1 1 つの cshttpd プロセスが多数の接続を許可しており、CPU 時間を 100% 使用している

1 つの cshttpd プロセスが多数の接続を許可しており、CPU 時間を 100% 使用している場合は、負荷分散が無効になっていることがあります。負荷分散をふたたび有効にするには、ics.conf パラメータ service.http.loadbalancing の値を "yes" に変更します。

Procedurestart-cal の問題の解決

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

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

  1. 設定権限を持つ管理者としてログインします。

  2. stop-cal コマンドを実行します。

  3. stop-cal コマンドがすべての Calendar Server サービスを停止できなかった場合は、子プロセスのいくつかが実行中であることがあります。この場合の処理については、「22.4.2 stop-cal の問題の解決」を参照してください。

  4. すべての Calendar Server プロセスが確実に終了したあと、start-cal コマンドを実行してすべてのサービスを起動します。次に例を示します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

22.4.2 stop-cal の問題の解決

ここでは、stop-cal の問題を解決するうえでの概念情報を提供し、その手順について説明します。

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

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

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 コマンドは、プロセスのリストではなく実行しているスレッドのリストを返します。プロセスだけが表示されるようにするための既知の解決策はありません。

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

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

  1. 前の手順 (「22.4.2 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 データキャッシュの設定方法については、「4.8 Calendar Server バージョン 6.3 の LDAP の設定」を参照してください。LDAP データキャッシュについては、『Sun Java Communications Suite 5 配備計画ガイド』を参照してください。

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

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

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

  2. CLD キャッシュをクリアします。「12.5 Calendar Server バージョン 6.3 での CLD キャッシュのクリア」を参照してください。

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

  3. stop-cal コマンドでサーバーを停止します。

  4. start-cal を使用して Calendar Server を再起動します。

22.4.4 カレンダが見つからない

CLD キャッシュオプションを使用していて、1 つ以上のカレンダを別のバックエンドサーバーに移動した (または、バックエンドサーバーの名前を変更した) 場合は、新規サーバーのカレンダが表示されないことがあります。

    その場合は、次の手順を実行します。

  1. CLD キャッシュをクリアします。「12.5 Calendar Server バージョン 6.3 での CLD キャッシュのクリア」を参照してください。

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

  2. これが失敗した場合は、正しい手順でカレンダを移動したかどうかを確認します。詳細は、

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

    その後、キャッシュをクリアします。

22.4.5 バックエンドマシンにカレンダを作成できない

指定したバックエンドマシンでカレンダを作成しようとすると、次のエラーメッセージが表示されます。Invalid DWP Host Server。この場合、原因は 2 つあります。サーバーが適切に設定されていないか、カレンダの所有者がすでに別のバックエンドサーバーに割り当てられています。

この節では、これら 2 つの問題の解決方法を説明します。

22.4.5.1 バックエンドマシンが適切に設定されていない

問題となっているバックエンドサーバーの ics.confファイルで、

次の設定があることを確認します。

service.dwp.enable = "yes"
caldb.cld.type = "directory"
local.hostname = "back-end hostname"

22.4.5.2 カレンダ所有者が別のバックエンドマシンに割り当てられている

ユーザーの LDAP エントリで、icsDWPHost 属性があることを確認します。icsDWPHost の値は、カレンダを作成しようとしているバックエンドサーバー名と一致する必要があります。このユーザーのカレンダを別のバックエンドサーバー上に作成することはできません。

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

この節では、失敗の原因として考えられるものについて説明します。示される手順を実行し、ログインを再試行します。

  1. この問題を解決するには、次のいずれかの手順を実行します。

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

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

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

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

  2. ログインを再試行します。

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

この節では、正しく完了しない検索のトラブルシューティングについての概念情報を提供し、その手順について説明します。

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

この節の内容は、次のとおりです。

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

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

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

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

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

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

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

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

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

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

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

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

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

    1. ディレクトリサーバーを停止します。

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

    3. ディレクトリサーバーを再起動します。

      注 –

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

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