execve文件没有find时,正在使用相同的文件!

我认识的某人在运行“ 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:用于GNU / Linux 2.4.0的ELF 64位LSB可执行文件,AMD x86-64,版本1(SYSV),用于GNU / Linux 2.4的dynamic链接(使用共享库)。 0,剥离
 ./bin.linux.x86/lmutil:用于GNU / Linux 2.2.5的ELF 32位LSB可执行文件,Intel 80386,版本1(SYSV),用于GNU / Linux 2.2.5的dynamic链接(使用共享库)剥离
 ./lmutil:Bourne shell脚本文本可执行文件

Solutions Collecting From Web of "execve文件没有find时,正在使用相同的文件!"

您尝试执行的文件( …/lmutil )存在,但其“加载程序”不存在,其中

  • 本地可执行文件的加载器是其动态加载器,例如/lib/ld-linux.so.2 ;
  • 脚本的加载程序是在它的shebang行中提到的程序,例如/bin/sh如果脚本以#!/bin/sh开头)。

从目录的名字来看, lmutil很可能是一个amd64 Linux二进制文件,寻找/lib64/ld-linux-x86-64.so.2作为它的加载器,但是你有一个amd64 Linux内核运行一个386即32位)用户级。 你需要为你的平台获得合适的二进制文件。

我认为这种情况是Unix最具误导性的错误信息。 不幸的是修复这个问题很困难:内核只能向程序的调用者报告一个数字错误代码,所以它只有“找不到命令”( ENOENT )的空间,而不是它所寻找的加载器的名字。 这是strace没有帮助的罕见情况之一。

您的ldd输出指向/lib64/ld-lsb-x86-64.so.3,但是除非(在Ubuntu上)您已经安装了lsb-core软件包,否则这个加载器可能实际上并不存在。 包的postinst脚本在/ lib *目录中创建相关的符号链接。

只是有点猜测,但我的第一个问题是,如果有这个问题的用户可以运行可执行文件本身没有strace。

另外execve手册页说,ENOENT将发生,如果无论是文件或所需的脚本interepreter或共享库不能找到。 (我注意到这里涉及64位内存,是否所有的库都可用?)

该文件是一个本地可执行文件还是可以是某种脚本?

这看起来像一个授权经理 – 任何有意难以调试的机会?

说到用户,是“tabitha”在其目录中的可执行文件所在的用户有问题吗? 或者我们正在寻找一种可能的并发症,试图运行一个由另一个普通用户安装的程序,而不是以一个普通的系统级的方式运行?

从execve手册页 :

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

strace假定-1表示“找不到文件”,因为errnoENOENT-1strace没有区分。

从本质上讲,你可以忽略这个: -1意味着发生了一些错误。 strace输出不会告诉你errno的值是多少。

我把这个作为一个警告调用来写出来,不要用strace和返回值来得出结论, 尽管可能会发现errno在这里是ENOENT

您可以使用readelf (任何readelf应该做的,你不需要从一个特殊的交叉编译器工具链)来检查动态加载或可执行文件预期哪个加载器。

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