跟踪同一文件时未找到 execve 文件！

Question

我认识的人在运行“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)

$ find . -name lmutil -exec file {} \;
./bin.linux.x86_64/lmutil: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), for GNU/Linux 2.4.0, stripped
./bin.linux.x86/lmutil: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped
./lmutil: Bourne shell script text executable

Answer 1

您尝试执行的文件 (.../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 中最具误导性的错误消息。不幸的是修复它会很困难：内核只能向程序的调用者报告数字错误代码，因此它只有“找不到命令”（ENOENT）的空间，而没有空间用于名称它正在寻找的装载机。这是 strace 没有帮助的罕见情况之一。

Answer 2

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

Answer 3

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

execve 手册页还指出，如果找不到文件或所需的脚本解释器或共享库，则会发生 ENOENT。 （我注意到这里涉及 64 位。所有正确的库都可用吗？）

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

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

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

Answer 4

您可以使用 readelf （任何 readelf 都可以，您不需要特殊的交叉编译器工具链中的一个）来检查动态加载或可执行文件需要哪个加载器。

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

Answer 5

来自 execve 手册页：

成功时，execve() 不返回，错误时返回 -1，并适当设置 errno。

strace 假设 -1 表示“找不到文件”，因为 errno 值 ENOENT 为 - 1 和 strace 没有区别。

本质上，您可以忽略这一点：-1 只是意味着发生了一些错误。 strace 输出不会告诉您 errno 的值是什么。

我写这篇文章是为了警告不要用 strace 和返回值得出结论，即使结果可能是 errno 是 ENOENT无论如何。

Answer 6

您可以看到 execve 返回 ENOENT 。然后在 execve man 中搜索 ENOENT。

文件路径名或脚本或 ELF 解释器不存在。

lmutil 文件存在，并且是 ELF 文件。因此检查ELF解释器是否存在。男子再次说道：

如果可执行文件是动态链接的 ELF 可执行文件，则
PT_INTERP段中命名的解释器用于加载所需的
共享对象。该解释器通常是 /lib/ld-linux.so.2
与 glibc 链接的二进制文件。

我们可以用readelf找到ELF解释器路径，正如@auselen所说：

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

ELF解释器不应该存在于这里。