第 7 章 エラーメッセージと障害追跡

この章では、Grid Engine システムのエラーメッセージ処理について説明し、一般的な各問題の解決方法のヒントを紹介します。

• 「ソフトウェアによるエラーレポートの検出方法」

• 「問題の診断」

• 「一般的な問題の障害追跡」

ソフトウェアによるエラーレポートの検出方法

Grid Engine ソフトウェアは、メッセージを特定のファイルに記録したり、電子メールを送信したり、またはこの両方を行って、エラーと警告をレポートします。ログファイルには、メッセージ ファイルとジョブ STDERR 出力が含まれます。

stderr ジョブが開始されると、ジョブ スクリプトの標準エラー (STDERR) 出力の出力先がファイルにリダイレクトされます。デフォルトのファイル名とファイルの保存場所を使用するか、qsub コマンドのオプションを使用してファイル名と場所を指定することができます。詳細は、Grid Engine システムのマニュアルページを参照してください。

sge_qmaster、sge_schedd、および sge_execd には、個別のメッセージファイルがあります。 ファイルの名前は同じで、messages です。sge_qmaster ログファイルは、マスタースプールディレクトリに保存されます。sge_schedd メッセージ ファイルは、スケジューラスプールディレクトリに保存されます。実行デーモンのログファイルの場所は、実行デーモンのスプールディレクトリです。スプールディレクトリについては、『Sun N1 Grid Engine 6.1 インストールガイド』の「ルートディレクトリの下のスプールディレクトリ」を参照してください。

各メッセージは、ファイル内の 1 行を占めます。各メッセージは、縦線記号 (|) で区切られた 5 つのコンポーネントに分割されます。

メッセージのコンポーネントは、次のとおりです。

1. 1 番目のコンポーネントは、メッセージのタイムスタンプです。

2. 2 番目のコンポーネントは、メッセージを生成する Grid Engine システムデーモンを指定します。

3. 3 番目のコンポーネントは、デーモンが動作しているホストの名前です。

4. 4 番目は、メッセージの種類です。メッセージの種類は、次のいずれかです。

   • 通知の N (情報提供が目的)

   • 情報の I (情報提供が目的)

   • 警告の W

   • エラーの E (エラー状態の検出)

   • 重大の C (プログラムの異常終了になる可能性あり)

   クラスタ構成で loglevel パラメータを使用して、グローバルまたはローカルベースで、記録するメッセージの種類を指定してください。

5. 5 番目のコンポーネントは、メッセージのテキストです。

   ---

   注 –

   なんらかの理由でエラーログファイルにアクセスできない場合、Grid Engine システムは、対応するホストのファイル /tmp/sge_qmaster_messages、 /tmp/sge_schedd_messages、または /tmp/sge_execd_messages にエラーメッセージを記録しようとします。

   ---

場合によって、Grid Engine システムは、ユーザー、管理者、またはその両方に電子メールでエラーイベントを通知します。Grid Engine システムが送信する電子メールメッセージには、メッセージの本文は含まれません。メッセージのテキストは、メールの件名フィールドにすべて含まれます。

異なるエラーコードまたは終了コードの意味

次の表に、複数のジョブ関連エラーコードまたは終了コードの意味を示します。これらのコードは、あらゆる種類のジョブに該当します。

次の表に、並列環境 (PE) 構成に関連するジョブのエラーコードまたは終了コードの意味を示します。

次の表に、キュー構成に関連するジョブのエラーコードまたは終了コードの意味を示します。これらのコードは、対応メソッドが上書きされた場合だけ有効です。

次の表に、チェックポイント設定に関連するジョブのエラーコードまたは終了コードの意味を示します。

正常に実行されたジョブに対して、qacct -j コマンドからの出力は、「failed」フィールドに「0」を示し、「exit_status」フィールドにジョブの終了ステータスを示します。ただし、シェパードがジョブを正常に実行できない場合があります。たとえば、epilog スクリプトが失敗したり、シェパードがジョブを開始できない場合があります。このような場合、「failed」フィールドは、次の表のコードの値のいずれかを表示します。

「コード」の列には、「failed」フィールドの値が一覧表示されています。「説明」列には、qacct -j の出力で表示されるテキストが一覧表示されています。acctvalid が t に設定されている場合、ジョブアカウンティングの値は有効です。acctvalid が f に設定されている場合、アカウンティングレコードのリソース使用率は有効ではありません。「ジョブに対する意味」の列では、ジョブが実行されたのかどうかが示されています。

デバッグモードでの Grid Engine システムのプログラムの実行

重大なエラーが発生した場合に、問題の特定に十分な情報がエラー記録機構によって生成されないことがあります。このため Grid Engine システムは、ほぼすべての補助プログラムとデーモンをデバッグモードで実行する機能が用意されています。デバッグのレベルは、提供される情報の量および深さに応じて異なります。デバッグのレベルは、0 から 10 の範囲で、10 はもっとも詳細な情報を提供するレベル、0 はデバッグ無効です。

デバッグレベルを設定するために、Grid Engine システムの配布には、.cshrc または .profile リソースファイルに対する拡張機能が用意されています。csh または tcsh のユーザーの場合は、ファイル sge-root/util/dl.csh が含まれています。sh または ksh のユーザーの場合は、対応するファイルの名前は sge-root/ util/dl.sh です。標準のリソースファイルに、これらのファイルを取り込む必要があります。csh または tcsh のユーザーの場合は、.cshrc ファイルに次の行を含めます。

source sge-root/util/dl.csh

sh または ksh のユーザーの場合は、.profile ファイルに次の行を含めます。

. sge-root/util/dl.sh

いったんログアウトして、ログインし直すと、次のコマンドを使用してデバッグレベルを設定できます。

% dl level

level が 0 より大きい場合、Grid Engine システムのコマンドを開始すると、トレース出力を STDOUT に書き込むようコマンドに強制します。トレース出力には、警告メッセージ、ステータスメッセージ、エラーメッセージ、および内部的に呼び出されたプログラムモジュールの名前が含まれます。メッセージには、ユーザーが指定するデバッグレベルに応じて、エラーの報告に役立つ行番号情報も含まれます。

デバッグトレースを監視するには、大きなサイズのスクロール行バッファーを持つウィンドウを使用するようにします。たとえば、1000 行のスクロール行バッファーを使用します。

ウィンドウが xterm の場合は、xterm ログ記録機構を使用して、あとでトレース出力を調べることができます。

デバッグモードで Grid Engine システムデーモンの 1 つを実行すると、デーモンが端末接続を維持して、トレース出力を書き出します。こうした端末接続は、使用している端末エミュレーションの割り込み文字を入力することによって打ち切ることができます。たとえば、Control-C などを使用します。

デバッグモードを無効にするには、デバッグレベルを 0 に戻します。

dbwriter デバッグレベルの設定

sgedbwriter スクリプトは、dbwriter プログラムを開始します。このスクリプトは、sge_root /dbwriter/bin/sgedbwriter に保存されています。sgedbwriter スクリプトは、dbwriter の構成ファイルである dbwriter.conf を読み取ります。この構成ファイルは、sge_root/cell /common/dbwriter.conf に保存されています。この構成ファイルは、dbwriter のデバッグレベルを設定します。例は次のとおりです。

#
# デバッグレベル
# 有効な値: WARNING、INFO、CONFIG、FINE、FINER、FINEST、ALL
#
DBWRITER_DEBUG=INFO

dbwriter コマンドの –debug オプションを使用すると、dbwriter により作成されるメッセージの数を変更できます。通常は、デフォルトのデバッグレベルである info を使用してください。より詳細なデバッグレベルを使用すると、dbwriter によって出力されるデータの量が大幅に増加します。

次のデバッグレベルを指定できます。

warning

重大なエラーと警告のみが表示されます。

info

多数の参考メッセージが追加されます。info がデフォルトのデバッグレベルです。

config

たとえば規則の処理に関する、dbwriter 構成に関連する追加の情報が得られます。

fine

さらに多くの情報が作成されます。このデバッグレベルを選択すると、dbwriter によって実行されるすべての SQL 文が出力されます。

finer

デバッグ用に使用します。

finest

デバッグ用に使用します。

all

すべてのレベルの情報を表示します。デバッグ用に使用します。

問題の診断

Grid Engine システムには、問題の診断に役立ついくつかの報告手段が用意されています。次の節では、それらの使用方法を簡単に説明します。

保留中のジョブが振り分けられない

保留中のジョブが実行可能な状態であることが明らかであるにもかかわらず、振り分けられない場合があります。Grid Engine システムには、その理由を診断するために、qstat -j job-id と qalter-w v job-id のユーティリティーとオプションのペアがあります。

• qstat -j job-id

  有効である場合は、qstat -j job-id は最後にスケジューリングが行われたときに特定のジョブが割り振られなかった理由のリストを示します。この監視は、有効または無効にすることができます。この監視機能は、schedd デーモンと qmaster との間の通信で望ましくないオーバーヘッドを引き起こす可能性があるため、無効にすることをお勧めします。sched_conf (5) のマニュアルページの schedd_job_info を参照してください。ID が 242059 のジョブに関する出力例を次に示します。

  % qstat -j 242059 scheduling info: queue "fangorn.q" dropped because it is temporarily not available queue "lolek.q" dropped because it is temporarily not available queue "balrog.q" dropped because it is temporarily not available queue "saruman.q" dropped because it is full cannot run in queue "bilbur.q" because it is not contained in its hard queuelist (-q) cannot run in queue "dwain.q" because it is not contained in its hard queue list (-q) has no permission for host "ori"

  この情報は、schedd デーモンによって直接生成されます。この情報の生成では、クラスタの現在の使用率が考慮されます。この情報には、必要な情報が含まれないことがあります。たとえば、ほかのユーザーのジョブによってすべてのキュースロットがすでに占有されている場合、問題のジョブに関する詳細なメッセージは生成されません。

• qalter -w v job-id

このコマンドは、基本的にジョブが割り振られない理由を一覧表示します。この目的のため、ドライスケジューリングが実行されます。スロットを含めて消費可能なすべてのリソースが、そのジョブ用に完全に利用可能であるとみなされます。同様に、負荷値も変化するため、すべての負荷値は無視されます。

エラー状態 E と報告されるジョブまたはキュー

ジョブまたはキューのエラーが、qstat 出力で、大文字の E で示されます。

ジョブがエラー状態になるのは、Grid Engine システムがジョブを実行しようとして、そのジョブに固有の理由で実行に失敗した場合です。

キューがエラー状態になるのは、Grid Engine システムがジョブを実行しようとして、そのキューに固有の理由で実行が失敗した場合です。

Grid Engine システムには、ジョブ実行エラーが発生した場合に、ユーザーおよび管理者がその診断情報を収集するための一連の機能が用意されています。キューおよびジョブのエラーの状態のどちらも、原因はジョブの実行失敗にあります。そのため、診断の機能は両方の種類のエラー状態に適用できます。

• ユーザー宛て中止メール。qsub -m a コマンドを使用してジョブが発行された場合は、-M user[@host] オプションで指定されたアドレスに中止メールが送信されます。中止メールには、ジョブエラーに関する診断情報が含まれています。中止メールを情報源として使用することをお勧めします。

• qacct アカウンティング。中止メールが得られない場合は、qacct -j コマンドを実行できます。このコマンドによって、Grid Engine システムのジョブアカウンティング機能からジョブのエラーに関する情報を入手できます。

• 管理者宛て中止メール。 管理者は、適切な電子メールアドレスを指定することによって、ジョブ実行時の問題に関する管理者宛てメールを送信するよう指示できます。sge_conf(5) のマニュアルページの administrator_mail を参照してください。管理者宛てのメールには、ユーザー宛ての中止メールよりも詳しい診断情報が含まれています。ジョブ実行エラーが頻繁に発生する場合に、管理者宛てメールを利用することをお勧めします。

• Message ファイル。 管理者宛てメールが得られない場合は、qmaster の messages ファイルをまず調べてください。適切なジョブ ID を検索することによって、特定のジョブに関するエントリを見つけることができます。デフォルトのインストールでは、qmaster messages ファイルは sge-root/ cell/spool/qmaster/messages に保存されています。

  ジョブの起動元の execd デーモンのメッセージに、補足情報が含まれていることもあります。qacct -j job-id を使用して、ジョブの起動元のホストを確認し、sge-root /cell/spool/host/messages でジョブ ID を検索してください。

一般的な問題の障害追跡

この節では、一般的な問題の原因の診断と対処に役立つ情報を説明します。

• 問題 — ジョブの出力ファイルに「Warning: no access to tty; thus no job control in this shell...」というメッセージが出力される。

  • 考えられる原因 — 1 つ以上のログインファイルに stty コマンドが含まれています。これらのコマンドが役立つのは、端末が存在する場合のみです。

  • 考えられる対策 — バッチジョブは端末に関連付けられません。すべての stty コマンドをログインファイルから削除するか、if 文で stty コマンドをまとめてください。if 文は、処理の前に端末をチェックします。次の例に if 文を示します。

    /bin/csh: stty -g # 端末の状態を確認します。 if ($status == 0) # 端末が存在すれば、 正常に終了します。 <put all stty commands in here> endif

• 問題 — ジョブの標準エラーログファイルに「`tty`: Ambiguous」というメッセージが出力される。しかし、ジョブスクリプトで呼び出されるユーザーのシェルには、tty に対する参照が存在しない。

  • 考えられる原因 — デフォルトでは、shell_start_mode は posix_compliant です。このため、すべてのジョブスクリプトは、キュー定義で指定されたシェルで実行されます。スクリプトは、ジョブスクリプトの先頭行に指定されたシェルでは実行されません。

  • 考えられる対策 — qsub コマンドに -S フラグを使用するか、shell_start_mode を unix_behavior に変更してください。

• 問題 — コマンド行からはジョブスクリプトを実行できるが、qsub コマンドを使用して実行すると、ジョブスクリプトが失敗する。

  • 考えられる原因 — ジョブに対するプロセス数が制限されている可能性があります。制限が設定されているかどうかをテストするには、limit と limit -h 関数を実行するテストスクリプトを作成してください。シェルプロンプトから qsub コマンドを使用して両方の関数を対話的に実行し、結果を比較します。

  • 考えられる対策 — 構成ファイルから、シェルで制限を設けるすべてのコマンドを削除してください。

• 問題 — 実行ホストから負荷 99.99 が報告される。

  1. 考えられる原因 — ホストで execd デーモンが動作していません。

     考えられる解決策 — 実行ホストで root になり、$SGE_ROOT/default/common/'rcsge' スクリプトを実行することによって execd デーモンを起動してください。

  2. 考えられる原因 — デフォルトドメインの指定に誤りがあります。

     考えられる解決策 — Grid Engine システムの管理者になって、qconf -mconf コマンドを実行し、default_domain 変数を none に変更してください。

  3. 考えられる原因 — qmaster ホストが認識している実行ホスト名と、実行ホストが認識している自身の名前が異なります。

     考えられる解決策 — 計算クラスタのホスト名の解決に DNS を使用している場合は、主ホスト名として絶対パスによるドメイン名 (FQDN) が返されるように /etc/hosts と NIS を構成してください。もちろん、168.0.0.1 myhost.dom.com myhost などの短い別名を定義して使用することができます。

     DNS を使用していない場合は、すべての /etc/hosts ファイルと NIS テーブルが、168.0.0.1 myhost.corp myhost または 168.0.0.1 myhost のように一致していることを確認してください。

• 問題 — 次のメッセージのような警告が 30 秒ごとに cell/spool/ host/messages に出力される。

  Tue Jan 23 21:20:46 2001|execd|meta|W|local configuration meta not defined - using global configuration

  しかし、cell/common/local_conf には、各ホスト用のファイルがあり、それぞれに FQDN が存在する。

  • 考えられる原因 — 使用しているマシン meta では、ホスト名解決でショート名が返されるのに対し、マスターマシンでは、FDQN 付きの meta が返されます。

  • 考えられる解決策 — この点に関して、/etc/hosts のすべてのファイルと NIS テーブルの間に矛盾がないようにしてください。この例では、ホスト meta の /etc/hosts ファイルに、誤って次のようなテキストの行が含まれている可能性があります。

    168.0.0.1 meta meta.your.domain

    正しくは、この行は次のようにします。

    168.0.0.1 meta.your.domain meta.

• 問題 — デーモンの messages ファイルに CHECKSUM ERROR、WRITE ERROR、または READ ERROR というメッセージが表示される場合がある。

  • 考えられる原因 — 1 秒間隔で出力されるのでない限り、何もする必要はありません。一般的にこれらのメッセージは、1 日に 1 から 30 回表示されます。

• 問題 — ジョブが特定のキューで終了し、qmaster/messages に次のメッセージを返す。

  Wed Mar 28 10:57:15 2001|qmaster|masterhost|I|job 490.1 finished on host exechost

  次に、実行ホストの exechost/messages ファイルには次のエラーメッセージが出力される。

  Wed Mar 28 10:57:15 2001|execd|exechost|E|can't find directory "active_jobs/490.1" for reaping job 490.1

  Wed Mar 28 10:57:15 2001|execd|exechost|E|can't remove directory "active_jobs/490.1": opendir(active_jobs/490.1) failed: Input/output error

  • 考えられる原因 — 自動マウントされる $SGE_ROOT ディレクトリがマウント解除されたため、sge_execd デーモンが現在の作業ディレクトリを失った可能性があります。

  • 考えられる解決策 — execd ホストにローカルのスプールディレクトリを使用してください。qmon または qconf コマンドを使用して、execd_spool_dir パラメータを設定してください。

• 問題 — qrsh ユーティリティーで対話型ジョブを発行すると、次のエラーメッセージが表示される。

  % qrsh -l mem_free=1G error: error: no suitable queues

  しかし、qsub コマンドを使用したバッチジョブの発行に対してキューは使用可能で、これらのキューは、qhost -l mem_free=1G と qstat -f -l mem_free=1G を使用して照会できます。

  • 考えられる原因 — 「error: no suitable queues」というメッセージの原因は、qrsh などの対話型ジョブに対してデフォルトで有効になる submit の -w e オプションにあります。qrsh(1) のマニュアルページの -w e を参照してください。現在のクラスタ構成に従ってジョブが振り分け可能であるかどうかを qmaster が確実に判断できない場合、このオプションがあると、submit コマンドで問題が発生します。この仕組みの意図は、許可できないジョブ要求を事前に拒否することです。

  • 対策 — この場合は、mem_free が消費可能リソースに設定されているにもかかわらず、ユーザーが各ホストで使用可能にするメモリーサイズを指定しなかったことが原因です。メモリー負荷値はそれぞれに異なるため、この検査ではメモリー負荷値は意図的に考慮されません。このため、クラスタ構成の一部としては表示されません。次のいずれかを行います。

    • qrsh のデフォルトオプションである -w e を -w n オプションに使用して明示的に無効にすることでこの検査を全般的に省略する。このコマンドを sge-root/ cell/common/cod_request に含めることもできます。

    • mem_free を消費可能リソースとして管理する場合は、qconf -me hostname を使用して、host_conf の complex_values にあるホストに対し mem_free の容量を指定する。

    • mem_free を消費可能リソースとして管理しない場合は、 qconf -mc hostname を使用して、complex(5) の consumable 列で消費不可リソースに再度戻す。

• 問題 — qrsh が自分のノードに振り分けられない。このとき qsh シェルから次のようなメッセージが返される。

  host2 [49]% qrsh -inherit host2 hostname error: executing task of job 1 failed: host2 [50]% qrsh -inherit host4 hostname host4

  • 考えられる原因 — gid_range が十分ではないことが考えられます。gid_range には、1 つの数字ではなく範囲として定義してください。Grid Engine システムは、ホスト上の各ジョブに固有の gid を割り当てます。

  • 考えられる解決策 — gid_range を qconf -mconf コマンドまたは QMON で調整してください。次のような範囲が考えられます。

    gid_range 20000-20100

• 問題 — 並列ジョブ内で使用すると qrsh -inherit -V が機能しない。次のメッセージが返される。

  cannot get connection to "qlogin_starter"

  • 考えられる原因 — この問題は入れ子にされた qrsh 呼び出しで発生します。問題の原因は -V オプションです。最初の qrsh -inherit 呼び出しでは、環境変数 TASK_ID が設定されます。TASK_ID は、並列ジョブ内の密接に統合されたタスクの ID です。2 番目の qrsh -inherit 呼び出しでは、この環境変数を使用してタスクを登録します。すでに実行中の最初のタスクと同じ ID を持つタスクを開始しようとするため、このコマンドは失敗します。

  • 考えられる解決策 — qrsh -inherit を呼び出す前に TASK_ID の設定を解除するか、-V ではなく -v オプションを使用してください。このオプションにより、実際に必要な環境変数だけがエクスポートされます。

• 問題 — qrsh がまったく機能していないように見える。次のようなメッセージが返される。

  host2$ qrsh -verbose hostname local configuration host2 not defined - using global configuration waiting for interactive job to be scheduled ... Your interactive job 88 has been successfully scheduled. Establishing /share/gridware/utilbin/solaris64/rsh session to host exehost ... rcmd: socket: Permission denied /share/gridware/utilbin/solaris64/rsh exited with exit code 1 reading exit code from shepherd ... error: error waiting on socket for client to connect: Interrupted system call error: error reading return code of remote command cleaning up after abnormal exit of /share/gridware/utilbin/solaris64/rsh host2$

  • 考えられる原因 — qrsh に対する権限が正しく設定されていません。

  • 考えられる解決策 — $SGE_ROOT/utilbin/ にある次のファイルの権限を確認してください。rlogin および rsh は、 setuid で、root に所有されていなければならないことに注意してください。

    -r-s--x--x 1 root root 28856 Sep 18 06:00 rlogin*

    -r-s--x--x 1 root root 19808 Sep 18 06:00 rsh*

    -rwxr-xr-x 1 sgeadmin adm 128160 Sep 18 06:00 rshd*

    ---

    注 –

    sge-root ディレクトリも setuid オプションで NFS マウントされている必要があります。sge-root が発行クライアントから nosuid でマウントされている場合、qrsh と関連するコマンドは機能しません。

    ---

• 問題 – 分散 make を開始しようとすると、qmake が次のエラーメッセージを表示して終了する。

  qrsh_starter: executing child process qmake failed: No such file or directory

  • 考えられる原因 — Grid Engine システムは、実行ホストで qmake のインスタンスを起動します。Grid Engine システム環境 (特に PATH 変数) がユーザーのシェルリソースファイル (.profile または .cshrc) に設定されていない場合、この qmake 呼び出しは失敗します。

  • 考えられる解決策 — -v オプションを使用して、PATH 環境変数を qmake ジョブにエクスポートします。一般的な qmake 呼び出しは次のようになります。

    qmake -v PATH -cwd -pe make 2-10 --

• 問題 — qmake ユーティリティーを使用すると、次のエラーメッセージが返される。

  waiting for interactive job to be scheduled ...timeout (4 s) expired while waiting on socket fd 5 Your "qrsh" request could not be scheduled, try again later.

  • 考えられる原因 — qmake の呼び出し元であるシェルに ARCH 環境変数が正しく設定されていない可能性があります。

  • 考えられる解決策 – クラスタで使用可能なホストに対応するサポート値を ARCH 変数に適切に設定するか、発行時に qmake -v ARCH=solaris64 ... などの適切な値を指定してください。

一般的なアカウンティングおよびレポートコンソールエラー

Version 2.0.3 の Sun Web コンソールのインストールが失敗し、次のエラーメッセージが表示される。

# ./inst_reporting
...
Register the N1 SGE reporting module in the webconsole

    Registering com.sun.grid.arco_6u3.

Starting Sun(TM) Web Console Version 2.0.3...
Ambiguous output redirect.

このバージョンの Sun Web コンソールは、ログインシェルとして /bin/sh を持つユーザー noacces のみがインストールできます。次のコマンドを使用してユーザーを追加します。

# useradd -u 60002 -g 60002 -d /tmp -s /bin/sh -c "No Access User" noaccess

簡単なクエリー定義の「table/view」ドロップダウンメニュー にエントリがないが、テーブルがデータベースで定義されている。

Oracle データベースを使用している場合に、通常、この問題が発生します。レポートモジュールのインストール時に、誤ったデータベーススキーマ名が指定されています。Oracle では、データベーススキーマ名は dbwriter によって使用されるデータベースユーザーの名前と同じになります。デフォルトの名前は arco_write です。Postgres では、データベーススキーマ名は public にしてください。

接続が拒否される。

smcwebserver が停止している可能性があります。smcwebserver を起動または再起動してください。

クエリーリストまたは結果リストが空である。

原因は次のいずれかが考えられます。

• データベースが停止状態です。データベースを起動または再起動してください。

• これ以上データベース接続を使用できません。データベースへの接続数を増やしてください。

• アプリケーションの構成ファイル内にエラーがあります。構成をチェックして、データベースユーザー、ユーザーパスワード、データベースの種類が誤ってないかどうか確認し、アプリケーションを再起動してください。

• クエリーを実行できません。クエリーディレクトリ /var/spool/arco/queries が空でない場合は、次のエラーが発生している可能性があります。

  • XML ファイルでのクエリーの構文が誤っています。XML パーサーからログファイルでエラーメッセージを確認してください。

  • ユーザー noaccess は、クエリーディレクトリへの読み取り権も書き込み権も持っていません。

使用可能なデータベーステーブルリストが空である。

原因は次のいずれかが考えられます。

• データベースが停止状態です。データベースを起動または再起動してください。

• これ以上データベース接続を使用できません。データベースへの接続数を増やしてください。

• アプリケーションの構成ファイル内にエラーがあります。構成をチェックして、データベースユーザー、ユーザーパスワード、データベースの種類が誤ってないかどうか確認し、アプリケーションを再起動してください。

選択可能なフィールドリストが空である。

テーブルが選択されていません。リストから表を選択します。

フィルタリストが空である。

フィールドが選択されていません。1 つ以上のフィールドを定義してください。

ソートリストが空である。

フィールドが選択されていません。1 つ以上のフィールドを定義してください。

定義したフィルタが使用されていない。

フィルタがアクティブでない可能性があります。未使用のフィルタを変更して、アクティブにしてください。

高度なクエリーの遅延結合が無視され、実行がエラーになる。

遅延結合マクロに構文エラーがあります。高度なクエリーの遅延結合マクロの正しい構文は、次のとおりです。

latebinding{attribute;operator}
latebinding{attribute;operator;defaultvalue}

前の画面に戻るために breadcrumb を使用したが、ログイン画面が表示された。

セッションがタイムアウトになっています。再度ログインして、セッション時間を app.xml で増やしてください。

ビュー構成を定義したが、デフォルト構成が表示されている。

定義されたビュー構成は表示設定になっていません。ビュー構成を開いて、使用するビュー構成を定義してください。

ビュー構成を定義したが、最後の構成が表示されている。

定義されたビュー構成は表示設定になっていません。ビュー構成を開いて、使用するビュー構成を定義してください。

クエリーの実行に時間がかかりすぎる。

データベースから得られた結果が膨大です。結果に制限を設定するか、フィルタ条件を追加してください。