execve файл не найден при размещении того же файла! - PullRequest
Новая
       17

execve файл не найден при размещении того же файла!

17 голосов
/ 08 марта 2011

кто-то из моих знакомых столкнулся с проблемой при запуске '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

Ответы [ 5 ]

14 голосов
/ 09 марта 2011

Файл, который вы пытаетесь выполнить (…/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 не помогает.

6 голосов
/ 14 апреля 2011

Ваш вывод ldd ссылается на /lib64/ld-lsb-x86-64.so.3, но этот загрузчик может фактически не существовать, если (в Ubuntu) вы не установили пакет lsb-core. Сценарий postinst для пакета создает соответствующие символические ссылки в каталогах / lib *.

3 голосов
/ 08 марта 2011

Немного спекуляций, но мой первый вопрос был бы, может ли пользователь, у которого возникла эта проблема, запустить исполняемый файл сам по себе без ограничений.

Также на странице руководства execve говорится, что ENOENT будет происходить, если не найден ни файл, ни требуемый интерпретатор сценария, ни общая библиотека. (Я заметил, что здесь задействовано 64-битное кодирование. Доступны ли все нужные библиотеки?)

Является ли файл собственным исполняемым файлом или это может быть какой-то скрипт?

Это похоже на менеджер лицензий - есть ли шанс, что он преднамеренно затруднил отладку?

Говоря о пользователях, находится ли tabitha в каталоге, исполняемый файл которого находится у пользователя, у которого возникла проблема? Или мы смотрим на возможное осложнение попытки запустить программу, установленную другим обычным пользователем, а не обычным общесистемным способом от root?

0 голосов
/ 03 ноября 2014

Вы можете использовать readelf (любой readelf должен делать, вам не нужен ни один из специального кросс-компиляторного набора инструментов), чтобы проверить, какой загрузчик ожидается от динамически загружаемого или исполняемого файла. 

$ readelf -l <filename> |grep -i interp
...
[Requesting program interpreter: /system/bin/linker]
0 голосов
/ 08 марта 2011

С execve manpage :

В случае успеха execve () не возвращается, при ошибке -1 возвращается и значение errno устанавливается соответствующим образом.

strace предполагает, что -1 означает «файл не найден», так как значение errno ENOENT равно -1, а strace не делает различий.

По сути, вы можете игнорировать это: -1 просто означает, что произошла какая-то ошибка. вывод strace не говорит вам, каково значение errno.

Я пишу это как предупреждающий вызов, чтобы не делать поспешных выводов с strace и возвращать значения , хотя может оказаться, что errno здесь ENOENT в любом случае .

...