19

私が知っている誰かが ' lmutil' の実行中に問題に遭遇したので、彼らに依頼しましたstrace -f lmutil。execve「No such file」で失敗するのはなぜですか!!! 私はまったく同じファイルを追跡しているので、意味がありません!! ここで正確に何が起こっているのですか？

strace -f /home/tabitha/Starprogram/FLEXlm_11.7/linux-x86_64-2.3.4/bin/lmutil

出力：

execve("/home/tabitha/Starprogram/FLEXlm_11.7/linux-x86_64-2.3.4/bin/lmutil", ["/home/tabitha/Starprogram/FLEXlm"...], [/* 38 vars */]) = -1 ENOENT (No such file or directory)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd7cb8b0000
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
close(3)                                = 0
munmap(0x7fd7cb8b0000, 4096)            = 0
exit_group(1)                           = ?

ldd 出力

$ ldd ./lmutil
        linux-vdso.so.1 => (0x00007fffcd5ff000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007fe40ebbe000)
        libm.so.6 => /lib/libm.so.6 (0x00007fe40e93b000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fe40e724000)
        libc.so.6 => /lib/libc.so.6 (0x00007fe40e3a1000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007fe40e19d000)
        /lib64/ld-lsb-x86-64.so.3 => /lib64/ld-linux-x86-64.so.2 (0x00007fe40edf5000)

$ 検索します。-name lmutil -exec ファイル {} \;
./bin.linux.x86_64/lmutil: ELF 64 ビット LSB 実行可能ファイル、AMD x86-64、バージョン 1 (SYSV)、GNU/Linux 2.4.0 用、動的にリンク (共有ライブラリを使用)、GNU/Linux 2.4 用。 0、ストリップ
./bin.linux.x86/lmutil: ELF 32 ビット LSB 実行可能ファイル、Intel 80386、バージョン 1 (SYSV)、GNU/Linux 2.2.5 用、動的にリンク (共有ライブラリを使用)、GNU/Linux 2.2.5 用、剥ぎ取られた
./lmutil: Bourne シェル スクリプト テキスト実行可能ファイル
4

5 に答える 5

18

実行しようとしているファイル ( …/lmutil) は存在しますが、その「ローダー」は存在しません。

  • ネイティブ実行可能ファイルのローダーは、その動的ローダーです。たとえば/lib/ld-linux.so.2、;
  • スクリプトのローダーは、たとえば、/bin/shスクリプトが#!/bin/sh.

ディレクトリの名前から、ローダーとしてlmutil探している amd64 Linux バイナリである可能性は十分にあり/lib64/ld-linux-x86-64.so.2ますが、386 (つまり 32 ビット) ユーザーランドを実行する amd64 Linux カーネルがあります。プラットフォームに適したバイナリを入手する必要があります。

私は、この状況が Unix の最も誤解を招くエラー メッセージであると考えています。残念ながら、これを修正するのは困難です。カーネルはプログラムの呼び出し元に数値のエラー コードしか報告できないため、「コマンドが見つかりません」( ENOENT) の余地しかなく、探しているローダーの名前を報告する余地はありません。straceこれは、役に立たないまれなケースの 1 つです。

于 2011-03-08T23:20:21.937 に答える
6

ldd の出力は /lib64/ld-lsb-x86-64.so.3 を参照していますが、(Ubuntu で) lsb-core パッケージをインストールしていない限り、このローダーは実際には存在しない可能性があります。パッケージの postinst スクリプトは、関連するシンボリック リンクを /lib* ディレクトリに作成します。

于 2011-04-14T14:28:52.100 に答える
3

ちょっとした推測ですが、私の最初の質問は、この問題を抱えているユーザーが strace なしで実行可能ファイルを単独で実行できるかどうかです。

また、execve のマニュアル ページには、ファイルまたは必要なスクリプト インタープリタまたは共有ライブラリが見つからない場合に ENOENT が発生すると書かれています。(ここには 64 ビット性が含まれていることに気付きました。すべての適切なライブラリが利用可能ですか?)

ファイルはネイティブの実行可能ファイルですか、それとも何らかのスクリプトでしょうか?

これはライセンス マネージャーのように見えます。意図的にデバッグしにくくしている可能性はありますか?

ユーザーといえば、実行可能ファイルが存在するディレクトリの「tabitha」に問題がありますか? それとも、ルートによる通常のシステム全体の方法ではなく、別の通常のユーザーによってインストールされたプログラムを実行しようとすると、複雑になる可能性があると考えていますか?

于 2011-03-08T17:33:43.463 に答える
2

動的にロードされた、または実行可能ファイルがどのローダーを予期しているかを確認するために (任意の readelfを使用するreadelf必要があります。特別なクロスコンパイラ ツールチェーンの 1 つは必要ありません) 使用できます。

$ readelf -l <filename> |grep -i interp
...
[Requesting program interpreter: /system/bin/linker]
于 2014-11-03T08:51:21.990 に答える
0

execveマンページから：

成功した場合、execve() は戻りません。エラーの場合は -1 が返され、errno が適切に設定されます。

strace値が-1「ファイルが見つからない」ことを意味し、区別しないと想定しています。errnoENOENT-1strace

基本的に、これは無視できます-1。単にエラーが発生したことを意味します。出力は、straceの値が何であるかを教えてくれませんerrno。

とにかくここにあることが判明するかもしれませんが、これを警告呼び出しとして書いて、strace値を返します。errnoENOENT

于 2011-03-08T15:02:06.290 に答える