一般的な問題の障害追跡

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

• 問題 — ジョブの出力ファイルに「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 で増やしてください。

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

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

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

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

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

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