一般的な問題の障害追跡

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

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

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

  • 対策 — バッチジョブは端末に関連付けられません。すべての stty コマンドをログインファイルから削除するか、if 文でstty コマンドを囲う必要があります。if 文は、処理前に端末の有無をチェックします。次の例に if 文を示します。

    /bin/csh: stty -g # checks terminal status if ($status == 0) # succeeds if a terminal is present <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. 原因 — ホストで sge_execd デーモンが動作していません。

     対策 — 実行ホストで root になり、sge-root/ cell/common/sgeexecd スクリプトを実行することによって sge_execd デーモンを起動します。

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

     対策 — Grid Engine システムの管理者として、qconf -mconf コマンドを実行し、default_domain 変数の値を none に変更します。

  3. 原因 — sge_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 には、各ホスト用のファイルがあり、それぞれに FDQN が存在する。

  • 原因 — 使用しているマシン 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 デーモンが現在の作業ディレクトリを失った可能性があります。

  • 対策 — sge_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 を参照してください。現在のクラスタ構成に従ってジョブが振り分け可能であるかどうかを sge_qmaster が確実に判断できない場合、このオプションがあると、submit コマンドで問題が発生します。この仕組みの意図は、許可できないジョブ要求を事前に拒否することにあります。

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

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

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

    • mem_free を消費可能リソースとして管理しない場合は、qconf -me hostname を使用することで、complex(5) の consumable カラムで mem_free を消費不可リソースに戻す。

• 問題 — 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 を割り当てます。

  • 対策 — qconf -mconf コマンドまたは QMON を使用して gid_range を調整してください。推奨する範囲は次のとおりです。

    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 ...)。

• 問題 — 次のジョブが SuSE Linux システムに割り当てられると、-cwd オプションが機能しないで、ユーザーのホームディレクトリに cwd-test が作成される。

  qsub -l arch=lx24-x86 -cwd -b y -o /dev/null -e /dev/null -V "hostname | tee -a cwd-test"

  • 原因 — SuSE Linux システムの場合、/etc/csh.login ファイルには、現在の作業ディレクトリをユーザーのホームディレクトリに変更する cd コマンドが含まれています。通常、シェルはシステム全体のプロファイルファイルを参照します。Linux の(t)csh の場合、システム全体のファイルは /etc/csh.login です。

  • 対策 – -noshell オプションを使用してください。この場合は、プロファイルファイルを参照することが可能な中間のシェルが存在しないため、~/.login または ~/.cshrc のどちらも参照されません。

    バッチスクリプトを使用するときは、あらゆるプログラムの実行前に、PWD 環境変数を使用して、そのバッチスクリプト内の現在の作業用ディレクトリを変更してください。

    これ以外の回避策は、ユーザーが tcsh または csh のどちらも使用しないことです。cd コマンドは /etc/csh.login にのみ現れるため、問題が起きなくなります。