caracteristicas - funciones de unix bsd

execve archivo no encontrado cuando stracing el mismo archivo!

Question

alguien que conozco se encontró con un problema al ejecutar '' lmutil '', así que les pedí strace -f lmutil . ¿Por qué falla execve con "No such file"? ¡No tiene sentido, ya que estoy encadenando el mismo archivo! ¿¿¿Qué está pasando aquí???

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

Salida:

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) = ?

salida 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

Su salida de ldd se refiere a /lib64/ld-lsb-x86-64.so.3, pero este cargador puede no existir a menos que (en Ubuntu) haya instalado el paquete lsb-core. El script postinst para el paquete crea los enlaces simbólicos relevantes en los directorios / lib *.

Answer 2

De la página de manual de execve :

En caso de éxito, execve () no devuelve, en el error -1 se devuelve, y errno se establece apropiadamente.

strace supone que -1 significa "archivo no encontrado" ya que el valor errno ENOENT es -1 y strace no hace una distinción.

Esencialmente, entonces, puede ignorar esto: el -1 solo significa que ocurrió algún error. la salida de strace no te dice cuál es el valor de errno .

Escribo esto como una llamada de advertencia para no saltar a conclusiones con valores de retorno y de strace , a pesar de que puede ser que ENOENT esté ENOENT aquí de todos modos .

Answer 3

El archivo que está intentando ejecutar ( …/lmutil ) existe pero su "cargador" no existe, donde

• el cargador de un ejecutable nativo es su cargador dinámico, por ejemplo /lib/ld-linux.so.2 ;
• el cargador de un script es el programa mencionado en su línea shebang, por ejemplo, /bin/sh si el script comienza con #!/bin/sh .

Desde el nombre del directorio, hay una buena posibilidad de que lmutil sea ​​un binario Linux amd64, buscando /lib64/ld-linux-x86-64.so.2 como su cargador, pero usted tiene un kernel Linux amd64 ejecutando un 386 ( es decir, 32 bits) userland. Debes obtener los binarios adecuados para tu plataforma.

Considero que esta situación es el mensaje de error más confuso de Unix. Desafortunadamente, solucionarlo sería difícil: el kernel solo puede informar un código de error numérico a la persona que llama del programa, por lo que solo tiene espacio para "comando no encontrado" ( ENOENT ) y no para el nombre del cargador que está buscando. Este es uno de estos raros casos en que strace no ayuda.

Answer 4

Solo un poco de especulación, pero mi primera pregunta sería si el usuario que está teniendo este problema puede ejecutar el ejecutable por sí mismo sin esfuerzo.

Además, en la página del manual de ejecución se indica que se producirá ENOENT si no se puede encontrar el archivo o un interepretador de script requerido o una biblioteca compartida. (Me doy cuenta de que hay 64 bits involucrados aquí. ¿Están todas las bibliotecas correctas disponibles?)

¿Es el archivo un ejecutable nativo o podría ser un script de algún tipo?

Esto se ve como un administrador de licencias: ¿hay alguna posibilidad de que se haya hecho intencionalmente difícil de depurar?

Hablando de usuarios, ¿está ''tabitha'' en cuyo directorio reside el ejecutable el usuario que tiene el problema? ¿O estamos viendo una posible complicación de intentar ejecutar un programa instalado por otro usuario ordinario en lugar de hacerlo a través de un sistema normal por root?

Answer 5

Puede usar readelf (cualquier readelf debería funcionar, no necesita uno de una cadena de herramientas de crosscompiler especial) para verificar qué cargador se espera cargado dinámicamente o ejecutable.

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