
現在、プラットフォームLSFを活用してジョブの実行を管理するいくつかのシェルスクリプトがあります。
これらのスクリプトは最終的に他のタスクスケジューラを使用して環境に移行されます。
移行段階で理想的な状況は、両方の環境で同じスクリプトを使用して作業スケジュールをサポートすることです。したがって、LSF 環境の存在を検出する場合は LSF 関連ガイドラインを使用し、そうでない場合は他の環境に関連するコマンドを使用します。
私はいくつかの可能な解決策を考えてみました。
LSF固有の環境変数の確認
たとえば
$LSF_BINDIR
、$LSF_LIBDIR
$LSF_SERVERDIR
if [[ -n $LSF_BINDIR ]]; then # Yes LSF else # No LSF fi
LSF固有のコマンドの可用性の確認
たとえば
which bsub
、which bhosts
which bjobs
if [[ -z $( which bsub 2>&1 | grep "/usr/bin/which" ) ]]; then # LSF present else # LSF absent fi
これらのチェックが十分かどうか、またはプラットフォームLSFがシステムに存在するかどうかを検出するより良い(ハッキングが少ない)より安定した方法があるかどうかはわかりません。
答え1
LSFを最後に使用してから数年が経過しましたが、LSF Bulk User Guide(バージョン3.2)で最初に述べたコマンドは、lsid
クラスタ名とマスターホスト名もインストールされているLSFバージョンとしてマークされます。
私の考えでは、このコマンドを、.exeなどのいくつかの一般的なユーザーユーティリティで確認することがLSFを検出する良い方法になるとbsub
思います。bjobs
私はこれら3つのユーティリティを含む他のカレンダーソフトウェアを知りません(しかし専門家ではありません)。
コマンドが現在のパスにあることを確認するには、代わりに使用しないでください(」を参照)which
。command -v
「which」を使わないのはなぜですか?それでは何を使うべきですか?"):
if (command -v lsid && command -v bsub && command -v bjobs) >/dev/null; then
echo "LSF seems to be available"
fi