web-dev-qa-db-ja.com

./executable：バイナリファイルを実行できません

サーバーにsshして自分で実行するときにうまく機能するスクリプトがありますが、継続的統合サーバーである Hudson を実行すると問題が発生します。

組み込みLinuxシステム（ターゲット）のテストを自動化しています。ターゲットはシリアル経由でサーバーA（RHEL 5）に接続され、minicom経由で操作されます。サーバーB（FC 12）は、ターゲットで実際に実行されるテストを構築し、サーバーAにSSHで接続できます。サーバーC（RH）は、サーバーBをスレーブとしてHudsonをホストします。

実際のターゲットで必要なすべてを実行するrunscript（http://linux.die.net/man/1/runscript）スクリプトを記述しました。イメージを起動し、サーバーBからディレクトリをマウントして、テストを実行します。サーバーBのbashスクリプトは、いくつかのコンパニオンアクションとともにrunscriptスクリプトを使用してminicomを呼び出します。私はサーバーBにbashスクリプトを持っています

ssh -t -t ServerA bashScript.sh

これらのテストをターゲットで実行します。私はサーバーCにいます。サーバーBにsshし、サーバーAにsshするスクリプトを実行して、runscriptでminicomを実行することで、これらのテストを実行できます。 ふew。確認するには：

サーバーA：Hudsonはスレーブメカニズムを使用してサーバーBにsshします。

サーバーB：kickOffTests.shにはssh -t -t ServerA runTests.shという行があります

サーバーA：runTests.shはminicom -S my.script ttyE1を呼び出すPerlスクリプトを呼び出します

ターゲット、起動後：サーバーBからテストが存在するディレクトリをマウントし、そのディレクトリに入ります。それは、コンパイルされたC実行可能ファイルであるテストを実行するさらに別のbashスクリプトを呼び出します。

これで、[〜＃〜] i [〜＃〜]がこれらのスクリプトを自分で実行すると、必要な処理が実行されます。ただし、Hudsonが同じことを行おうとすると、minicomセッションで、C実行可能ファイル./executableを./executable: cannot execute binary fileで呼び出す「まだ別のbashスクリプト」の行について文句を言います。

Linuxについてはまだ多くのことを学ぶ必要がありますが、この問題はHudsonがコンソールに接続していないことが原因であると思います。ハドソンが奴隷を制御するために何をしているのか正確にはわかりません。 kickOffTests.shを実行する直前の設定でexport TERM=consoleという行を使用してみましたが、問題は解決しません。

誰かが私に何が起こっているのか、そしてどうすればそれを修正できるのか説明できますか？この方程式からサーバーを削除することはできません。 minicomを方程式から外すことは可能かもしれませんが、このプロジェクトに未知の時間を追加することになるので、私はすでに持っているものを使用するソリューションをはるかに好みます。

bashshell-scriptexecutable
12
jasper77

メッセージcannot execute binary fileは端末とは関係ありません（何が原因だと思いましたか。また、質問でこのような仮定をしないことをお勧めします。それらは、赤いニシンの混乱で実際の問題を溺れさせる傾向があるためです）。実際、これはbashがENOEXECを表現する方法です（より一般的にはexec format errorとして表現されます）。

まず、この実行可能ファイルを誤ってスクリプトとして実行していないことを確認してください。 . ./executableを記述した場合、これはbashに、（別のプロセスではなく）呼び出し元のスクリプトと同じ環境で./executableを実行するよう指示します。ファイルがスクリプトでない場合、それはできません。

それ以外の場合、このメッセージは、./executableがカーネルが認識する形式ではないことを意味します。何が起こっているのか、私にははっきりとした推測はありません。別の方法で起動して同じマシンでスクリプトを実行できる場合、それは破損したファイルや間違ったアーキテクチャー用のファイルではない可能性があります（その可能性がありますが、それだけではありません）。ターゲットの起動方法（おそらく競合状態）に違いがあるのではないかと思います。

役立つかもしれない追加データのリストはここにあります：

  • サーバーBでのfile …/executableの出力。
  • uname -aの出力がunixに似ている場合など、ターゲットに関するいくつかの情報。
  • ターゲットが毎回同じファイルの内容を確認することを確認します。cksum ./executableまたはmd5sum ./executable、またはまだ別のbashスクリプトが./executableを呼び出す直前にターゲットで実行しているメソッドを実行します。 Hudson呼び出し、成功した手動呼び出し、およびサーバーBで結果が同じであることを確認します。
  • もう1つのbashスクリプトの先頭（set -x行のすぐ下）に#!/bin/bashを追加します。これにより、スクリプトが実行するすべてのトレースが生成されます。トレースを比較し、違いや奇妙さを報告します。
  • スクリプトを手動で実行したとき、およびHudsonが関与したときに、ターゲットがどのように起動するかを説明します。ターゲットの起動方法が異なり、Hudson呼び出しで./executableの形式のサポートを提供する一部のロード可能なモジュールがロードされない（またはまだロードされていない）可能性があります。他のスクリプトでset -xを使用して、そこから支援し、ターゲットからのブートログを検査することができます。
13
Gilles 'SO- stop being evil'

これは、スクリプトの上部にあるシバン行が欠落している場合に発生する可能性があります。スクリプトが次で始まることを確認してください：

#!/bin/bash

これは、Sudo -u <user>を使用してスクリプトを実行したときにのみ表示されました

0
Kevin Lamse