Файл определенно существует. Получите «Нет такого файла или каталога» при попытке запустить его
Вскоре ответ будет:
приложение javascript отправляет и получает данные в/из 104.31.112.90 :8880.
Для того, чтобы узнать, что я использовал с успехом:
telnet 104.31.112.90 8880
Это означает, что наиболее вероятный 8880 не является случайным портом, как если бы изначально ко мне был подключен 104.31.112.90; это также означает, что каким-то образом именно я инициировал подключение к 104.31.112.90 :8880. После дальнейших раскопок я обнаружил, что 104.31.112.90 — это сервер cloudflare; наиболее вероятно, что это сервер, на котором размещена какая-то веб-служба, которую я использовал.
Учитывая, что у меня уже был открыт браузер со многими вкладками, скорее всего, приложение javascript использовало некоторые веб-службы с 104.31.112.90 :8880. Игнорирование портов 53, 80, 123, 443 при использовании iftop не помогло. с уже запущенным javascript в уже открытых вкладках браузера.
Эта команда исправила это для меня в 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 "$@"
What gives? Why am I getting "No such file or directory"?
Это хорошо известная бородавка. Несмотря на отображение пути к двоичному файлу, сообщение об ошибке касается динамического компоновщика/интерпретатора 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)
После Google я подозреваю, что эта команда просто отказывается запускаться из командной строки и подделывает это сообщение.
Question Because the licensing service isn't a 'service' on a Mac (we use install_fnp.sh to generate a setuid-root binary that gets invoked by Flex-enabled applications via our libraries), this brings up the question, how long does FNPLicensingService normally stay running after the last client disconnects?
Существует также множество предупреждений о том, что вредоносное ПО часто связано с этим программным обеспечением. Предостережение.
Думаю, проблема может заключаться в том, что sudo выполняет только те команды, которые существуют в каталогах, указанных в secure_pathв /etc/sudoersили в $PATH, если secure_pathне установлено. Хотя в этом случае обычное сообщение об ошибке command not found.
Вы можете попробовать добавить каталог с исполняемым файлом в secure_pathи посмотреть, что получится.
Также убедитесь, что в файле установлен исполняемый бит:chmod +x FNPLicensingService