扫描同一个文件时未找到execve文件！

我认识的某个人在运行“

lmutil

”时遇到问题，所以我让他们

strace-f lmutil

。为什么

execve

因“没有这样的文件”而失败！！！这毫无意义，因为我正在扫描同一个文件！！这里到底发生了什么

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) $ldd./lmutil linux vdso.so.1=>（0x00007fffcd5ff000） libpthread.so.0=>/lib/libpthread.so.0（0x00007fe40ebbe000） libm.so.6=>/lib/libm.so.6（0x00007fe40e93b000） libgcc_.so.1=>/lib/libgcc_.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） $find-名称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可执行文件，英特尔80386，版本1（SYSV），适用于GNU/linux 2.2.5，动态链接（使用共享库），适用于GNU/linux 2.2.5，剥离 ./lmutil:Bourne shell脚本文本可执行文件 发件人：

如果成功，则不返回execve（），如果出现错误，则返回-1，并正确设置errno

strace

假设

-1

表示“未找到文件”，因为

errno

值

enoint

为

-1

，

strace

没有区别

基本上，您可以忽略这一点：

-1

只意味着发生了一些错误。

strace

输出不会告诉您

errno

的值

---

我写这篇文章是为了警告大家不要对

strace

和返回值下结论，即使结果可能是

errno

在这里是

enoint

。

只是一点猜测，但我的第一个问题是，有此问题的用户是否可以在没有strace的情况下自行运行可执行文件

另外，execve手册页面还指出，如果找不到文件或所需的脚本interepreter或共享库，则将发生eNote。（我注意到这里涉及64位ness。所有正确的库都可用吗？）

该文件是本机可执行文件还是某种脚本

这看起来像是一个授权管理器-它有没有可能故意使自己难以调试

---

说到用户，可执行文件所在目录中的“tabitha”用户是否有问题？或者，我们是否正在考虑尝试运行由另一个普通用户安装的程序而不是以root用户的正常系统范围方式安装的程序的可能复杂性？

您尝试执行的文件（

../lmutil

）存在，但其“加载程序”不存在，其中

• 本机可执行文件的加载程序是其动态加载程序，例如

  /lib/ld linux.so.2

• 脚本的加载程序是其shebang行中提到的程序，例如，如果脚本以

  #开头，则为
  /bin/sh
  /bin/sh

从目录名来看，

lmutil

很有可能是一个amd64 Linux二进制文件，寻找

/lib64/ld-Linux-x86-64.so.2

作为它的加载程序，但是您有一个运行386（即32位）用户区的amd64 Linux内核。您需要为您的平台获取合适的二进制文件

---

我认为这种情况是UNIX最容易出错的错误信息。不幸的是，修复它会很困难：内核只能向程序的调用者报告一个数字错误代码，因此它只有“command not found”（

enoint

）的空间，而没有它要查找的加载程序的名称。这是一种罕见的情况，

strace

不起作用。

您的ldd输出引用/lib64/ld-lsb-x86-64.so.3，但除非（在Ubuntu上）安装了lsb核心包，否则此加载程序可能实际上不存在。包的postinst脚本在/lib*目录中创建相关的符号链接。

您可以使用

readelf

（任何readelf都应该这样做，您不需要特殊的交叉编译器工具链中的一个）来检查动态加载或可执行文件需要哪个加载程序

$ readelf -l <filename> |grep -i interp
...
[Requesting program interpreter: /system/bin/linker]

$readelf-l | grep-i interp
...
[请求程序解释器：/system/bin/linker]

谢谢！我还发现了这篇文章：哦，这是一个很好的文档。此外，如果答案正确，则意味着我的答案是错误的不，您读取的

strace

输出错误

execve

返回-1，

enoint

是调用

execve

后

errno

的值@Gilles:就像你没有读我之前的评论一样。@Tomalak:如果你意识到你的答案是错误的，请编辑它来修正它。“我的答案错了”的评论对读者没有帮助：答案应该是独立的，即使他们读了评论，在我写这篇文章的时候，他们也不会知道什么是错的，除非他们也读了我的评论。它也是一个二进制文件-file/whatever/lmutil。该软件包是由用户在其笔记本电脑上安装的，因此它不是remoteFS.ignore查找-名称lmutil-exec文件{}\；（该输出不是由用户生成的）这是一个错误，需要编辑掉。@Paleyviener:那么

ldd./lmutil

呢，它是在您试图扫描的同一个可执行文件上运行的吗？缺少加载程序是我能想到的执行现有文件失败的唯一解释，因为

enoint

，所以我也倾向于怀疑报告的这一部分。@Gilles:你刚刚救了我一命！这正是我的问题所在（我试图在64位Ubuntu 12.04安装上运行一个32位可执行文件，但没有意识到这一点），只是发出了

sudo apt get install ia32 libs

就解决了这个问题。@reinierpost on Ubuntu 12.04，y

$ readelf -l <filename> |grep -i interp
...
[Requesting program interpreter: /system/bin/linker]