stracing非常相同的文件时，没有找到execve的文件！ [英] execve file not found when stracing the very same file!

问题描述

我认识的人运行时，遇到了一个问题 lmutil '，所以我要求他们 strace的-f lmutil 。为什么的execve 以没有这样的文件失败！这是没有意义的，因为我straceing非常相同的文件！到底是怎么回事就在这里？

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

输出：

 的execve（/家庭/大比/ Starprogram / FLEXlm_11.7 / Linux的x86_64-2.3.4 /斌/ lmutil，[/家/大比/ Starprogram / FLEXlm的 ...]，[/ * 38 *瓦尔/）= -1 ENOENT（没有这样的文件或目录）
DUP（2）= 3
的fcntl（3 F_GETFL）= 0x8002（标志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（非法寻求）
写（3，strace的：EXEC：没有这样的文件或二......，40strace：EXEC：没有这样的文件或目录
）= 40
附近（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的可执行文件，英特尔80386，版本1（SYSV），为GNU / Linux 2.2.5，动态链接（使用共享库），为GNU / Linux 2.2.5，剥离
./lmutil：Bourne shell脚本文本可执行

解决方案

您正试图执行的文件（ ... / lmutil ）存在，但它的加载没有按T存在，其中

• 本机的可执行文件的加载器是它的动态加载，例如 /lib/ld-linux.so.2 ;


• 脚本加载器是它的家当线，如 / bin / sh的如果脚本是以＃！/中提到的程序bin / sh的。

从目录的名称，有一个很好的机会， lmutil 是AMD64的Linux二进制文件，寻找 / lib64目录/ LD-Linux的x86-64.so.2 为装载机，但你有一个AMD64的Linux内核中运行的386（即32位）用户态。你需要得到合适的二进制文件的平台。

我认为这种情况是Unix的最误导性的错误消息。不幸的是固定这将是很难：内核只能报一个数字错误code到程序的调用者，所以它只有空间（找不到命令 ENOENT ），而不是对装载机的名字它寻找。这是这些罕见的情况下， strace的不帮一把。

someone i know encountered a problem when running 'lmutil' so i asked them to strace -f lmutil. Why is execve failing with "No such file"!!! It makes no sense, since I am straceing the very same file!! What exactly is going on here???

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

Output:

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 output

$ 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

解决方案

The file you're trying to execute (…/lmutil) exists but its "loader" doesn't exist, where

• the loader of a native executable is its dynamic loader, for example /lib/ld-linux.so.2;
• the loader of a script is the program mentioned on its shebang line, e.g., /bin/sh if the script begins with #!/bin/sh.

From the name of the directory, there's a good chance that lmutil is an amd64 Linux binary, looking for /lib64/ld-linux-x86-64.so.2 as its loader, but you have an amd64 Linux kernel running a 386 (i.e. 32-bit) userland. You need to get suitable binaries for your platform.

I consider this situation to be Unix's most misleading error message. Unfortunately fixing it would be hard: the kernel can only report a numeric error code to the caller of the program, so it only has room for "command not found" (ENOENT) and not for the name of the loader it's looking for. This is one of these rare cases where strace doesn't help.

这篇关于stracing非常相同的文件时，没有找到execve的文件！的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！