Isso está no Arch Linux. Dê uma olhada neste:
[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
Então existe com certeza. Ldd mostra que todas as bibliotecas estão vinculadas. O arquivo mostra que é um elfo de 64 bits (e estou em uma instalação de 64 bits).
O que da? Por que estou recebendo "Esse arquivo ou diretório não existe"?
Responder1
Este comando corrigiu isso para mim no Arch Linux, permitindo-me executar o binário elf:
sudo pacman -Syy ld-lsb lsb-release
Para outros sabores de Linux,
Você deve instalar opacote ld-lsb(ou lsb-compat
qualquer pacote semelhante que contenha ld-lsb-x86-64.so.3
) ou crie um script wrapper/executável que inicie seu programa por meio do vinculador dinâmico existente:
#! /bin/sh
/usr/lib64/ld-linux-x86-64.so.2 ./FNPLicensingService "$@"
O que da? Por que estou recebendo "Esse arquivo ou diretório não existe"?
Essa é uma verruga bem conhecida. Apesar de exibir o caminho do binário, a mensagem de erro é sobre o vinculador dinâmico/interpretador ELF exigido pelo binário não existente, e não sobre o binário em si.
A saída de ldd
NÃO informa se o vinculador dinâmico realmente existe; ldd
hoje em dia usa um vinculador dinâmico de uma lista de "caminhos seguros" em vez daquele gravado no binário, para evitar que usuários que executam ldd
binários aleatórios se prejudiquem. E sua saída também é confusa e enganosa no caso de binários cujo intérprete não existe. Exemplo simples:
$ 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)
Responder2
Acho que o problema pode ser que o sudo executa apenas comandos que existem nos diretórios especificados no secure_path
in /etc/sudoers
ou no $PATH
if secure_path
não está definido. Embora neste caso a mensagem de erro usual seja command not found
.
Você pode tentar adicionar o diretório com um executável secure_path
e ver como funciona.
Certifique-se também de que o arquivo tenha um bit executável definido:chmod +x FNPLicensingService
Responder3
Depois do Google, suspeito que esse comando esteja apenas se recusando a ser executado na linha de comando e falsificando essa mensagem.
Pergunta Porque o serviço de licenciamento não é um 'serviço' em um Mac (usamos install_fnp.sh para gerar um binário setuid-root queé invocado por aplicativos habilitados para Flex por meio de nossas bibliotecas), isso levanta a questão: por quanto tempo o FNPLicensingService normalmente permanece em execução após a desconexão do último cliente?
Também há vários avisos de que malware está frequentemente associado a este software. Cuidado recomendado.