Это на Arch Linux. Взгляните на это:
[saint-llama@hubs bin]$ lsattr
--------------e----- ./install_fnp.sh
--------------e----- ./toolkitinstall.sh
--------------e----- ./FNPLicensingService
[saint-llama@hubs bin]$ file FNPLicensingService
FNPLicensingService: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-lsb-x86-64.so.3, for GNU/Linux 2.6.18, stripped
[saint-llama@hubs bin]$ ldd FNPLicensingService
linux-vdso.so.1 (0x00007ffcbafd8000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f870ce06000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007f870cdfb000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f870cdd9000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f870cc93000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f870cc79000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f870cab2000)
/lib64/ld-lsb-x86-64.so.3 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f870ce60000)
[saint-llama@hubs bin]$ sudo ./FNPLicensingService
sudo: unable to execute ./FNPLicensingService: No such file or directory
Так что он точно существует. Ldd показывает, что все библиотеки связаны. Файл показывает, что это 64-битный эльф (а у меня 64-битная установка).
Что происходит? Почему я получаю сообщение «Нет такого файла или каталога»?
решение1
Эта команда исправила эту проблему в Arch Linux, позволив мне запустить двоичный файл elf:
sudo pacman -Syy ld-lsb lsb-release
Для других версий Linux,
Вам следует либо установитьпакет ld-lsb(или lsb-compat
любой аналогичный пакет, содержащий ld-lsb-x86-64.so.3
) или создайте оболочку/исполняемый скрипт, который запускает вашу программу через существующий динамический компоновщик:
#! /bin/sh
/usr/lib64/ld-linux-x86-64.so.2 ./FNPLicensingService "$@"
Что происходит? Почему я получаю сообщение «Нет такого файла или каталога»?
Это хорошо известная бородавка. Несмотря на отображение пути к бинарному файлу, сообщение об ошибке касается динамического компоновщика / интерпретатора ELF, требуемого бинарным файлом, который не существует, а не самого бинарника.
Вывод ldd
НЕ говорит вам, существует ли динамический компоновщик на самом деле; ldd
в настоящее время используется динамический компоновщик из списка "безопасных путей" вместо того, который встроен в двоичный файл, чтобы пользователи, работающие ldd
со случайными двоичными файлами, не навредили себе. И его вывод также сбивает с толку и вводит в заблуждение в случае двоичных файлов, интерпретатор которых не существует. Простой пример:
$ cp /bin/sh /tmp/sh
$ patchelf --set-interpreter /no/such/file /tmp/sh
$ /tmp/sh
bash: /tmp/sh: No such file or directory
$ ls /tmp/sh
/tmp/sh
$ file /tmp/sh
/tmp/sh: ELF 64-bit LSB ..., interpreter /no/such/file, ...
$ ldd /tmp/sh => /foo/bar => /lib64/ld-linux-x86-64.so.2
...
/no/such/file => /lib64/ld-linux-x86-64.so.2 (0x00007fc60d225000)
решение2
Я думаю, проблема может быть в том, что sudo выполняет только команды, которые существуют в каталогах, указанных в secure_path
в /etc/sudoers
или в $PATH
если secure_path
не задано. Хотя в этом случае обычное сообщение об ошибке command not found
.
Вы можете попробовать добавить каталог с исполняемым файлом secure_path
и посмотреть, что из этого получится.
Также убедитесь, что у файла установлен исполняемый бит:chmod +x FNPLicensingService
решение3
После Google я подозреваю, что эта команда просто отказывается запускаться из командной строки и подделывает это сообщение.
Вопрос Поскольку служба лицензирования не является «службой» на Mac (мы используем install_fnp.sh для генерации двоичного файла setuid-root, которыйвызывается приложениями Flex с помощью наших библиотек), возникает вопрос: как долго FNPLicensingService обычно продолжает работать после отключения последнего клиента?
Также есть куча предупреждений о том, что вредоносное ПО часто связано с этим программным обеспечением. Рекомендуется осторожность.