私は、Octave の openmpi を使用して、リモート マシン上の他の Octave インスタンスを起動しようとしています。さまざまなプロセスを起動するスクリプトを実行すると、ライブラリが古くなっているというエラーが表示されます。
Running octave in parallel on /opt/data/octave/test using 24 processors
[pleasant-increase:13959] Warning: could not find environment variable "LD_PRELOAD"
[octave-controller:15259] mca: base: component_find: unable to open /usr/lib/openmpi/lib/openmpi/mca_paffinity_hwloc: perhaps a missing symbol, or compiled for a different ver$
[octave-controller:15259] mca: base: component_find: unable to open /usr/lib/openmpi/lib/openmpi/mca_carto_auto_detect: perhaps a missing symbol, or compiled for a different v$
[octave-controller:15259] mca: base: component_find: unable to open /usr/lib/openmpi/lib/openmpi/mca_carto_file: perhaps a missing symbol, or compiled for a different version $
[octave-controller:15259] mca: base: component_find: unable to open /usr/lib/openmpi/lib/openmpi/mca_shmem_mmap: perhaps a missing symbol, or compiled for a different version $
[octave-controller:15259] mca: base: component_find: unable to open /usr/lib/openmpi/lib/openmpi/mca_shmem_posix: perhaps a missing symbol, or compiled for a different version$
[octave-controller:15259] mca: base: component_find: unable to open /usr/lib/openmpi/lib/openmpi/mca_shmem_sysv: perhaps a missing symbol, or compiled for a different version $
--------------------------------------------------------------------------
It looks like opal_init failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during opal_init; some of which are due to configuration or
environment problems. This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
opal_shmem_base_select failed
--> Returned value -1 instead of OPAL_SUCCESS
--------------------------------------------------------------------------
[octave-controller:15259] [[INVALID],INVALID] ORTE_ERROR_LOG: Error in file runtime/orte_init.c at line 79
--------------------------------------------------------------------------
It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or environment
problems. This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):
ompi_mpi_init: orte_init failed
--> Returned "Error" (-1) instead of "Success" (0)
--------------------------------------------------------------------------
*** An error occurred in MPI_Init
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL: your MPI job will now abort
これは様々なプロセスで継続され、いくつかのライブラリは異なりますが、常に
opal_shmem_base_select failed
...
ompi_mpi_init: orte_init failed
openmpi のコンパイル フラグを変更して再コンパイルするようにというコメントを見ました。
問題は、マシンのプロビジョニングにローカルの juju リポジトリを使用していることです。プロビジョニングが発生したときに、juju が現在使用しているバージョンではなく、ライブラリをロードするための場所がわかりません。パッケージがどこかに保存されることはわかっています。それらが juju ステート マシン上にあるのか、juju サーバー上にあるのか、それとも juju が独自の apt-get パススルー チャネルとして機能するのかはわかりません。
どのようなアイデアでも歓迎します。
2015.04.28 1723PST に追加 - Robie Basak への返信 ---------------------------------------------------
ホルヘ・カストロさん、ご褒美をありがとう
私のクラスタはネットに接続されていません。MaaSコントローラは今のところ接続されていますが、将来的には切断される予定です。jujuをセットアップしたとき、私はローカルリポジトリを使用しました。
juju sync-tools -e maas --local-dir="~/.juju/sync-tools"
juju bootstrap -e mass --debug --upload-tools=true --metadata-source="~/.juju/sync-tools" --to jujuBS.maas
juju deploy --repository=".juju/charms" local:juju-gui --to 0
juju expose juju-gui
私は、オクターブ チャームとオクターブ コントローラ チャームに同じメカニズムを使用しました。ノードの 1 つにある /var/log/juju のユニット... ログ ファイルを見ると、多くの apt がロードされているのがわかります。ノードはネットにアクセスできないため、これらはどこかに保存されます。
これらのいくつかはチャームのロードの結果としてロードされるので、MaaS または juju のいずれかがチャームの apt 要件を認識しているようです。私はいくつかの octave パッケージをチャームとインストールに追加し、octave がそれらをインストールしたのですが、突然、必要な apt が不足していることがわかりました。これらの apt は明らかに octave パッケージに必要です (open-mpi もその 1 つでした)。私はこれをダウンロードし、チャームに追加してインストールしました。これで MPI パッケージが octave にロードされますが、上記のステータスが表示されます。
答え1
簡単に答えると、あなたがコントロールできます。チャームのinstallフックで好きなことをすることができます。デフォルトでは、MAAS の squid-deb-proxy がプロキシ キャッシュとして動作するメインの Ubuntu アーカイブを使用します。アクティブな個別のミラーやリポジトリはありません。
MaaS コントローラーは現在接続されていますが、将来的には切断される予定です。
MAAS が提供する squid-deb-proxy を使用していると思います。これはパッケージをキャッシュしますが、それ以上のことはしません。デフォルトでは、チャーム インストール フックが参照する環境は、パッケージをダウンロードするために MAAS が提供する squid-deb-proxy を使用するように適切に構成されていますが、sources.listメインの Ubuntu アーカイブを指しています。つまり、パッケージは、パッケージ キャッシュとして MAAS を介して Ubuntu アーカイブから取得されます。
代わりにカスタム パッケージを使用するように設定するには、まず apt を再構成して、チャームinstallフックを変更してカスタム パッケージを使用するようにします。たとえば、変更したパッケージで PPA を設定し、フックがそれを使用するように設定することができますinstall。
sourceこの一般的な例は、チャーム設定オプションの実装で確認できます。mariadb チャームの設定変更フック汎用的である必要のないカスタムチャームの場合は、次のような行を追加するだけです。
sudo add-apt-repository -y ppa:username/octave
フックにパッケージをインストールする前install、またはチャームが別の言語で記述されている場合は適切な同等のものをインストールします。
MAAS マシンをインターネット アクセスから切断する場合は、独自のローカル apt リポジトリを実装し、それを優先して使用するように MAAS マシン上の squid-deb-proxy を設定するかarchive.ubuntu.com(ミラーリングしていると仮定)、インストール フックを設定して apt がそれを使用するように設定する必要があります。